Video details

Java in the Age of Containers and Serverless (Markus Eisele, 2019)

Serverless
11.04.2021
English

Java in 2019 was predicted to be business as usual by many. We have seen new Java releases coming out as planned, AdoptOpenJDK became the main trustful source of binaries and Oracle fighting for the trademark again by preventing the use of javax as namespace.
Everything looks like it would be a silent year for Java. But one thing seems also obvious. Java's popularity is not gaining any more traction. New language features keep it up to date but people are getting more selective when it comes to implementation choices. Especially in the age of containers and cloud infrastructures. How will Java continue to fit in? What are the advantages and what needs to be done?

Transcript

It's actually wonderful to be here for many, many, many reasons, because first of all, I'm not talking that much anymore in terms of giving talks in places. The main reason for that is I shifted more into the developer relations director role, so starting to be responsible for our own events from a light bend perspective, we're running scholars. We're running a great conference that is called Reactive Summit. Scholars just ended was in Louzan. It was the 15th year anniversary of the language, so pretty big deal. And I still have a lot of history in Java in particular. And I have to admit, I'm getting old because I think I started programming in Java when many, many people didn't even know what Java was. And if I say it's like 17 years ago, even 18 by now, that really makes me old. But good news is there's been a lot of stuff that I could do in the past couple of years. So the first 14 years of my career, I was actually just a consultant in the field, working on a day to day basis, like many of you probably do, trying to bring new technologies and most likely solutions to customers that have some kind of pain. And starting with J two E servers and in particular, be a Web logic server back in the day, we built some incredibly big applications and the lessons I learned during these 14 years of consultancy, I always wanted to kind of employ and share and make people aware to not trap into the same pitfalls over and over again. So this is kind of how I came into that director position into that developer advocacy role because it was far more fulfilling for me to orchestrate a learning experience, an onboarding experience for new technologies for people to actually solve problems than it was to actually implement them in some kind of fancy basement in random automotive OAM in Southern Germany. Right? And because all of that still didn't fulfill me personally, I also found some time to create my own conference, which is called Java Land. I don't know if you guys have heard about it. My only prerequisite for that conference was that I didn't want it to be at another hotel somewhere. And I told the team to find me something that is super cool. And guess what? They came up with theme park roller coasters. So Javaland is actually happening in Germany's oldest theme park, which is called Fantasyland and the roller coasters. They're amazing. So first night of the conference, you got to write all the roller coasters, all the rides for free. And you got a lot of Java learning to go. I mean, those are two packed days of conferences and another two days of workshops afterwards. Make sure to check that out. We're here to talk about something that is pretty close to my heart. I told you that I'm in that kind of Java ecosystem since way too many years already. And let me see by show of hands, who is actually a Java developer right here a lot. Thank you. So Java has been going through a lot of changes, like looking back to my first contact with Java, to Sun Microsystems, to Oracle, taking sun over to Oracle steward shipping Java developing everything further. There has been a lot of excitement. There's been a lot of disappointment. There's been a lot of things that might actually have been good things turned out to be bad things and vice versa. Right. So a lot changed. The question is, why are we still talking about Java? It is an old technology. Some people call it legacy. Some people say JavaScript isn't. The next thing like Java is nothing that we actually need to care about anymore. Right. So here's a nice flight that is actually stolen from an Eclipse presentation. But yeah, the reason for that, obviously is Jakarta EE. So after many years of struggles and no further development in Oracle, Java E as a specification was released into the wild, at least most of it. And the Eclipse Foundation is trying to be the new, better steward for Java E, the container specification. Right. So they are trying to get a handle on what is so important. What is so interesting with the Java E platform specification? And if you just look at the sheer numbers here, tell 10 million plus Java developers worldwide, like as of today, you could probably just go outside the street, grab a random student or guy who looks like a student or women or whatever and ask them to implement a surflet, and they would probably know how to do that. So there's a lot of knowledge available. Fortune 500 have used Java EE as a platform over the years to standardize their application development models. There has not been a question if you want to use Java EE or if you can use. The question was if it was a red shade, like coming from Oracle being a WebLogic server, if it has blue shade coming from IBM being a WebSphere application server. Right. So there has never been a question about standard platform decisions being made. And just looking at the sheer number of companies who are betting their application technology on Java, like almost to 100%. Java is something that is built into Fortune 5000, actually so deeply that if you learn Java as of today, you'll still have a wonderful salary and totally can retire with Java as your main language spoken. But there's this TLB programming language index. People love it. People hate it. It's one of the biggest indices around programming languages. Attractiveness. Maybe what we see here is that's not a success story, is it? What's your take Java is losing, right? I mean, what is that? 15%. And the next run up is C. And after that, it's C Plus Plus. So first of all, yes, you're right. Java is losing traction. Definitely in the total overview just compared with 2002 in this case. Right. But if you still look at the percentages compared to JavaScript, which is probably 8% right now, if I remember correctly, this is still a lot of ground, and probably Java is not going to lose that anytime soon. There's still a lot of base knowledge about a lot of people who are actually able to programming in Java. And I found this neat little T shirt on Twitter just a couple of days ago, Heather Vancouver posted it. She's seen it somewhere on a Java conference. And yes, why not? I mean, this is what many people feel like. Many people who love Java and who learn to work with Java on a daily basis. They still feel that. And I have to admit, I'm one of them. Have you ever looked at JavaScript? Like, who is a JavaScript programmer? Here one. Okay. Now you're what do you like better? Javascript is better than PHP. Okay. There's two languages. Language. The proper language is a C in Java. I've been stuck in PHP, so moving to JavaScript is actually a big impression. That's actually a nice comparison I can totally get with. So if you're looking at proper languages, JavaScript is not so. Yeah. Burn me on that one. Another great quote that totally fits into that story. Right. People complain about stuff that they are actually working with. If you're not using, if you're not having a relation with something that doesn't really touch your heart, you're not talking about it. It just is not interesting to you. Right. So as long as we're all talking about Java, as long as people have opinions around Java, this is probably also not going to change. So what has changed? How has Java changed over the years? And this is a wonderful animation. Thanks to my designer. It started out pretty easy with pretty simple steps. Every three years we went all the way into the sun. Oracle kind of mess, where we had no releases in a while, where there's been a couple of things that nobody really want us to talk about. And just recently, Oracle stepped up the game a little bit and started releasing six months cycles around new features in Java. And with a little bit of luck, we'll have JavaScript March 2021, which is kind of surprising coming all the way from Java one0 and 1997. But yeah, so it's vibrant. It's Lifely, right? I mean, things are happening and don't get me wrong. Even if you have no clue about what it really means to actually develop Java as a language, including the JVM itself, the JVMs, I should say, including the JDKs, meaning the libraries and all the features you can use. Besides the core language, there is a large amount of people involved in developing these kind of functionalities that we technically took for granted for very long. We just went to Java. Oracle. Com. We clicked. Okay. When it came to the OTN license and we just downloaded whatever was there and used it as a JDK, right? Like nobody questioned that. I should have asked you on which versions you are, but I think this is a pretty quick answer from the latest JetBrains Developer survey. It's not a big surprise, is it like Java Eleven is way out. It's not even the latest release by now, right? I mean, we're cooking Java 13 right now. So Java Twelve is out. Java Nine brought the new module system, Java Ten. Nobody used at all. Java Eleven is still pretty new to all of us. And I think legacy systems or stuff that really runs in Fortune 500 companies is probably still using Java Eight. Is that saying anything like, does it worry us? Should it worry us? Actually, probably not. So if you look at the Twitter timelines of certain very vocal people in the Java community, you'll find out that you have seen this kind of adoption leak with pretty much every major version change. So people are not just jumping onto the latest and greatest. I mean, otherwise we all would have Tesla's, probably by now. Right. So we're waiting for stuff to happen, for stuff to mature, actually, to make a difference. And we're not just jumping on the next version of anything without reason except you're buying Apple products. But other than that, this is a total normal perception on what's happening in the Java ecosystem right now. A little bit of a lag. I expect that to shift comparably quickly, following patterns in the past. And if you look at the things that we actually got as like new toys just in the past couple of versions, Lambdas and Java Eight, we got our module system in Java Nine. So who's actually using the module system as of today? Like zero. Nobody, right? Yeah, it is exhausting. It's not even fun to use, and it has never been designed to be used by developers, but we will get used to it and we will use it over time. So how do I migrate Java Ten to Java Eleven? Even? Have we thought about that now? Why should we? Because we're all still using Java Eight. Right. So there's so much coming at us, the new release process, figuring out what a long term support LTS version actually means for me personally, if that is not exciting, I can't help you if you want to have more exciting stuff to look at, tell me what it could be, but it's definitely not even close to this excitement. How did we get here? Good question. How did we get here? Let's look at the past a little bit more. Why are people still stuck with Java Eight? What's the kind of, like, short version of history going from the very left. Big Iron, IBM mainframes sitting somewhere. Technical support. I might need a beer. No, I'm record. Okay, so Big Iron, the idea was to have some kind of centralized, really big hardware that we can run stuff on. This is where start procedures kind of originated. That was a centralized database with built in logic that could execute lightning fast. That didn't work because it didn't scale very well. It was super expensive, and you couldn't move it out of the data center if it was on fire. So we came to the enterprise idea to the idea of shared hardware. Instead of having a lot of super expensive things, we decided to have a lot of inexpensive things, even more inexpensive things. We thought about them as like those little pizza boxes that you can just slide into 19 inch rack. And that do just one thing on commodity hardware speaking, intel processors. Right. So we had a lot of them. We thought about scaling. We thought a little bit about availability, that's the life and time and probably the high time of application service, where we try to figure out how to make our applications resilient on more than one system and the actual technology reality we're living in as of today, that is all cloud based. That is virtualized. That is virtualized at best, that's distributed that's sitting in other people's data centers. That is no longer anything that we even buy a host in our own basements. Right. We're just using Amazon, IBM, Oracle, whatever clouds out there. And I'm not getting paid by any of these for mentioning them. And if you follow our application design principles throughout these years and developments, you can easily see where microservices are coming from. Right? It's not about keeping businesses entertained by rewriting applications. It's not about keeping you as developers busy. By reimplementing your existing applications, it is to actually make your systems fit for new infrastructures that are coming or even there. So instead of putting a big Java E application server into Docker containers, which is like swallowing a horse into Anaconda, we really want to have something lightweight. We want to have something that we can scale easily that has a lightning fast startup, and that is part of a big system. This is why microservices actually come into play. So it's not about anybody being angry about you. So you can just learn what microservices are, learn what distributed systems are. I actually have a couple of nice talks. So if you are searching for me on YouTube, you might want to watch these. Ok. Back to that JDK and Java stuff. Everything was so easy when it was just Oracle. As I said, Java, Oracle dot com is gone more or less. No, it's still there, actually. But now we have SAP machine. Jesus, has anybody heard about the JVM that is called or SAP Machine? Yes. Believe it or not, SAP released the complete JDK. So now you can decide where you want to grab your Java from. Like, which flavor do you want to have a submarine or a dancing Duke from Azul? That is interesting. Isn't that. So adopt OpenJDK is my shorthand solution for you guys here. Instead of just looking at all the available JVMs out there that you might even not even have heard about. Go to adopt OpenJDK. Those guys, the London Java community, Martin Verbal is doing a tremendous job hurting all the community people around who are spending so much energy and creating the central landing place for you to grab a reasonable Java version that is built, and you can even choose between two different compilers. You can choose between Openj Nine as a VM or the standard Hotspot, and so this is where you have to go first. And if you're done with that, if you want to look into alternatives for reasons, then you might look into what all the other vendors have to offer. The good news is they all have to follow the same licenses when it comes to the open source downloadable artifacts. They have different terms when it comes to support contracts. And this is something that I had a little discussion with one of my former bosses on Twitter just a couple of weeks ago. Imagine or not, he now works for AWS, and he and his team put a tremendous effort into releasing Koretto as an Open JDK version so you can go to Amazon and download your Java flavor, and they tend to suggest that you get support without paying as a free download for everybody. And this might have been a missing comma in a sentence or not. Ultimately, if you dig into their license agreements, you'll find out that Koreto actually has support for customers who are on AWS. So if you're running Java workloads on AWS, you might actually want to look into Koretto because it's supported by Amazon. If you're running Karado somewhere in Azure for fun or not for profit, you probably don't have support. So I'm pointing you to a couple more general thoughts here around what could be interesting with the new distributions out there and point you at the biggest names. There's a little link underneath. And I told a couple of people I do have two girls, eight and ten. And boy, believe me, I always hated homework when I was in school, and now that I'm a parent, I hated even more. It sucks so hard to see those little ladies having to sit at a table, and I thought during my presentations I could do something for you guys. So in the best vein of trying to figure out the positive side of homework, I created slide decks that have this little eight point URLs down there. And whenever you see one of these little eight point URLs, you can consider that your personal homework. So if you get hands on the slides afterwards, either over my own SlideShare channel or via Skills Matters, you can easily just read what's underneath there. It will probably lead you down the whole rabbit hole about how to pick which to pick and which the right distributions are. This particular article was written by the Java Champions and details in depth what distributions are out there, what to watch out for and which are the ones that you can easily choose right now. Jakarta EE? Yeah. Somebody asked me about my Jakarta EE sticker here and there's something else. Micro profile. Right. So I talked earlier about Oracle having released Java EE as a platform specification. As hopefully all no Java E and Java have very little to do with each other. It's more like a platform definition that builds on top of Java as a language and gives a little bit more enterprise features around building enterprise applications. And Java E was released to the Eclipse Foundation with a bunch of exceptions, and the biggest exceptions are actually trademarks and naming rights. And I'm not going to ask you whoever implemented some Java E specification, but let me tell you that if you have you've written something like as a package import that names javax whatever and end it in a technology name surflet, for example, or Persistence JPA or whatever acronym. And even JPA is Java. Persistence contains the name Java. So if we now look through all the Java EE APIs out there and we can imagine that Oracle didn't release the Java name as a trademark to the Eclipse Foundation, that basically means that Jakarta E is going to look a little different going forward compared to what Java E as a platform meant. Ultimately, do I like it? Am I afraid about it? I dislike it heavily because I do think just imagine the uncountable number of books, blog posts, documentation, articles, magazine articles printed or online that reference some kind of Java package name or technology that will be named differently going forward. So if a newbie starts to search for a persistent entity that is part of a Java X JPA package, it will not be found like people can't find information about technologies that have matured over the last double digit number of years. So we will have to create a tremendous amount of bridging documentation, blog posts. We will have to help the community to make that transition. Every single application will have to undergo certain amounts of transitions in that kind of space. There are tweaks there's magic you can do compile time, magic rewriting packages, there's magic. You can do even runtime bytecode replacements. But all this magic will only carry you so far unless you will have to touch the application for maintenance reasons. Right. So this is a tremendous loss of knowledge in general. And just because Oracle is sitting on that trademark, there's no technical merit. So it's just Oracles, right for that trademark. This makes me sad. Another thing makes me very happy. There's another project called MicroProfile, which was brought to life even before Oracle actually donated the Java E source codes and test suites. Right. And it was led by a lot of individuals backed by Red hat as a company, the idea was to make Java E more competitive in the microservices frame. We wanted to have something that is more suitable to individual applications running on JVM that is more suitable to individual microservices instead of spinning up a weblogix server or a webphere. And I'm deliberately taking those two names as examples for the biggest chips in the application server market. You can even distantly think about micro profile has been and still is a very good step in the right direction. I believe it is a very good common ground for many technologies to actually derive from just the GitHub repository into something that could be a de facto standard. The positive side here is there is no history, there is no Java package name, there is no nothing that collides with trademarks. So if you followed these kind of efforts from the very beginning, you could just go on with a micro profile. And if we are all honest and just look at what Java E actually brings to the table as of today, when we're looking at cloud optimized microservice infrastructures, it actually is very little like we don't want heavyweight Ejbs and a very teensy individual microservice. Right? So kind of sad, kind of happy because it makes a clear cut between legacy and stuff that's happening in the future. But that was only one part of the metal so far. We only talked a little bit about deployment models and architectures. Right. I haven't really touched on the things that the business side of the house are actually pushing for. And I brought you this. Any guesses before everybody sleeps off? What this could actually be? There is this headline that should have been removed, but no, we're all fine. At least we're awake. So, yes, the number of devices or computers or, let's say, devices connected to the Internet grew tremendously over the last years. Everybody is wearing some kind of Apple Watch fitness tracker knows what's next. Right. I've seen the first Bose sunglasses that have headphones built in and stuff like it's getting crazy. But yes. So expectation is there is going to be a lot more wearables that are reasonable, and there's going to be a lot more people on the planet that actually want to wear these kind of devices. So the baseline is faster, more easier for people and a lot cheaper because we don't want to pay that much for every single device anymore. And that kind of is also the baseline for the innovation that happened in the past around Java. We've been pretty good in building these big monolithic blocks, and we've been pretty good in optimizing them when it comes to performance. We've been really, really good in pushing Java to the limit when it comes to looking at the business qualities of the applications built on top of Java. So what we found looking at Moore's Law like double computing power over time, we can see Java supporting that kind of development over time, very consistently with developer productivity features, with performance features that ultimately led to the fastest runtime environments you can find. There's no faster and no better runtime environment than the JVM. Funny enough, the JVM itself scales to all kinds of devices, like even your credit cards. They have this little chip on it. There's Java on this chip. That's a teensy little bit of Java. That's not a full blown JDK, but it's still Java, and it also goes all the way up to the biggest mainframes where we could still run Java. And we've tweaked the best performance out of the JVM runtimes that we could even distantly find. And the compilers that have been developed over the past couple of years are the greatest compilers. I sound like Trump didn't, don't I? Java is pretty cool. Let's make Java. No, I'm not saying that. So today that is today, right? That is today. Clouds distributed applications. So is Java fit to support distributed applications as of today as a programming language as the on top platforms that we have? I kind of talked about that, right. Java EE as the main platform to me personally, is not a couple of specifications might be suitable. So looking at something like the micro profile might be a good start. Java as a language. What about Java as a language like the compiler? What about the runtime? The JVM itself? Is that like, would you run Java applications in the cloud? What about Go? Isn't that the container thing everybody is doing? And why are they doing it? Okay, step back. Let's try to dissect that a little bit. Typical Java application memory usage. You have some kind of let me see if I have a little bit. Yeah, I do have explanations. You have a starter black. It takes a little bit for the JVM to actually warm up. And if you've ever done reasonably big applications, and if you've ever tried to load, test these on reasonably sized production environments, meaning more than one server. Speaking of four, with 16 or 64GB of Ram, you will see exactly that kind of pattern, and it's easily measurable. So JVMs need a warm up need to start collecting. Need to have the garbage collection runs going back into some kind of predictable cycles. So this startup lag also leads to a little bit of how did I call this over peak usage? Yeah, a little bit more memory than we actually planned it to be in production. Right. So over peak usage, typical Java application. You can try that with every reasonably sized one as of today. Does that make any sense? Like, are we getting the most out of today's container infrastructures with these kind of profiles? Okay, I'm asking. We're not in school. No, we don't. So the reason is today we have Kubernetes, we have container orchestration tools. We have containers. We want to spin up our application parts, our microservices within milliseconds we want them to be there and we want them to use as little memory as possible and exactly no over peaks usage. I mean as little as possible in general, because memory usage are dollars on. Aws. If you ever played around with AWS, I've been paying a 40 cent bill for the last couple of months because I couldn't figure out which resource was producing these $0.40 every single month. Aws, you pay for every kilobyte you're using for every CPU hour. So the little money you spend on not really application critical memory, that is what you really want. So an ideal profile looks more like this spinning up in milliseconds using exactly the defined amount of memory that we want to give to that container for the application or the microservice to perform. That's exactly what we need. Nothing more. Are we there yet? Can we do that as of today? So the immediate goal to me personally for the JVM to survive and Java as a language going forward, we need to adapt to the challenges that are existing as they are today. I personally think it's not a big secret. It will be containers. It will be container orchestration. I can tell if Kubernetes will be the deep layer that we as developers will have to handle going forward. There's a bunch of abstractions going on right now. You might have heard about Istio and Knative on top. These are all already application centered abstractions on top of just Orchestration and containers. I'm not sure if Docker is going to be the solution as the container itself. There's also an open container project. There's stuff like potman happening in the Redhead realm, so just from a technical perspective, that's going to be interesting. Do we need a mic? I have a question. Oh, yeah. I know you don't need a mic, but they need a mic. Hasn't this problem been sold to the Gravm because it basically compiles the binary before. So you don't actually have adjusting time in it. Look at the last bullet point here. There definitely is a little bit going on here, so yes, we want to achieve a very small footprint. Yes, we want to have a faster startup time. Yes, the Java team is not sleeping. They are definitely not ignoring what today's technical merits are giving them as business inputs from users. I mentioned substrate down here graviam. That is for sure one of the fastest ways, but it also has drawbacks. There are a couple of things that are just not possible right now. Reflection just one example can't use it. So need to find ways around Kwacos from Redhead open source project. They have two different ways of generating microservices out of their framework. One is Grass substrate images. They have native images on the JVM, and they actually tweaked a couple of Java EE frameworks and specifications, namely Hibernate as JPA implementation to be able to run and substrate images. But yeah, that is one way. Possibly. There's also a bunch of features coming out of the JVM or the JDK. In general, a couple of jets proposed for the next couple of development iterations. We have new garbage collection strategies, the fastest ones, the best ones for small heaps, for super large heaps. So low, latency and high performance is definitely the big theme going forward when it comes to solving problems and issues in Java for today's problems. Right? What's tomorrow today's? Easy. Today is like we're living in today and nobody's sleeping. So tomorrow is interesting. What's happening tomorrow in Java? Is it going to be JavaScript or Go or Python, as somebody mentioned. But you mentioned Python, right? No, Python is amazing. It's a really great way for data analytics. Everybody who's trying to do anything looking into machine learning algorithms. There's a lot of Python in that space. There's not a lot of Java, and I think one of the reasons for it is that it actually needs a JVM, and it's not lightning fast. We do have something like J shell, though, that makes it easy to execute individual statements. Is that enough for tomorrow? Maybe? I don't know. So we have a bunch of new challenges here. First of all, this is something new to me. Came up a couple of times before when people talked about large scale deployments, especially Netflix sized deployments. Netflix is not testing locally. Why are they not ideas? They bluntly cannot because they can't reproduce production. It's too expensive, like they have one system and that's done. They do functional tests, for sure. Nothing is probably untested in production, but just from a low test perspective, they are not testing locally or even in a test environment. So we are about to embark on systems that are way too much and way too complex, way too big to even distantly be tested, probably even functionally tested locally. While Netflix only has to deal with the aspect of load testing in AI and machine learning driven systems, they might actually have functional aspects that we can any longer test locally. We might actually have to deal with models, machine learning models that we need to train and deploy. This is stuff that doesn't happen locally. There will also be a lot of things going forward. That mean there are third party services that are no longer libraries that you can just package as part of the JDK somewhere, but that are somewhere kind of cloud services that we all just use. And I keep hearing Watson AI in the back of my head, which is an IBM product. So marketing works. Obviously. I don't know. Amazon probably has some kind of AI APIs already available, too, but yeah, that stuff needs to be available to Java developers. We need to have some kind of handle on new proprietary APIs, and we need to need a way to actually link them into our Java applications. Going forward. I mean, three tier applications are no longer suitable that's yesterday already. Right. But just thinking about machine learning models and how they come to life within complex data flowoperating applications. Like we're dealing with data that never ends. We're dealing with people who actually are sending life data from their fitness trackers. As of today, we're still syncing. Right. So those things have Bluetooth connection to our phone, and there's a bunch of data that's just being uploaded and processed at some point. But we're getting into more and more business requirements where we actually have to handle life data. People are driving places and they are sending live data and insurances are calculating if that guy is driving too fast, if he is like, probably having a very hostile driving style, and if he has to pay more insurance rates at the end of the day, this is stuff you can't just like when you come back home, your car is probably not going to sync up to your WiFi and collect your driving behavior. That's probably not going to happen. Your car is probably life sending your motion data, maybe even acceleration or God knows what. Like, there are so many business models we're not even thinking about right now that the technology itself opens up to us that need to be in some way captured going forward, closer to the language. Still speaking of Java here. Right. That's a set of new tricks left to right. Like, we need to be able to transform data that's coming in in terms of streams. And I'm not talking about the shitty ways that streams are implemented in many, many parts of especially higher level platforms on the Java ecosystem right now. Problem partitioning features. Yeah, that's kind of think about Hadoop. Think about how large calculations are actually separated into various chunks of data and think about parallel execution and summarizing all the execution results. Think about distributed systems running in different data centers, even and taking full advantage of an almost infinite number of available JVMs as of today. Like, just thinking about fork join framework in Java, there's very little that supports us when it comes to executing these kind of things. I'm not saying there are no technical ways to make that happen. Yes, there are companies producing various tools. There are tools like in memory data grids, for example, that you could technically use for these kinds of things. But I think it's not necessary to actually make your stack more complex. So looking at the language and the way that we are going to develop applications going forward, I personally think we need to change the language into the direction of the business requirements coming at us. Instead of thinking of building blocks and packaging more weights and technical depth on our way forward. You'Re looking for a new paradigm to write computer programs. Couldn't agree more. Yeah, definitely. But you need a way to run it under the hood, and technologies are out there like Hazel costs that can execute it's funny enough. Because you always have many ways to tackle a problem. Right. So you can even stack and slice parts of Java as a platform and still make it usable in the context of microservices. You can even have a very low footprint. Jvm as of today, look at Openj Nine, for example, and ahead of time compilation features, and you can have a lot of individual technology solutions to meet your particular baseline when it comes to business or technical or non functional requirements. Right. I think if we look a little bit further ahead in a more broader sense, you will realize that the number of screws you need to tighten to solve the growing complexity of new requirements will be tremendously growing. This is literally what I'm asking to put a lot of these intelligence that is coming at us as developers into our base platform that we all love. Right? I mean, that's basically the approach optimized hardware. That's another fancy thing. And I have to thank a very nice colleague for thinking that through even before me, and it ended up being just a bullet point in this list without even homework for you guys. But yes, we are not using any specialized hardware right now, like there's a little bit of GPU acceleration in UI components, and I think that Java in particular, has a couple of things going on there. But if we're just looking at the specialized hardware that are available that you can pre program to do one specific part, it could also be a tremendous thing to use from a Java perspective and solving extremely complex mathematical problems or analytic problems going forward. This is a field that is completely blank right now. When we look at Java in particular, is that everything we have like there's day after tomorrow. And now I really want to know what your day after tomorrow technology would be. So we scratched a lot. We scratched containers, we scratched a little bit of new hardware, AI machine learning. So what's after that. I would use Hazel. I have no idea what you mean. Can Hazelcast do that? What is that? That is actually a quantum computer, and it's actually an unwrapped one. So technically speaking, this is just the uncooled version. You can't see a working quantum computer because it's cooled down to literally almost zero degree centigrade, and it's completely covered with material. I have no picture of this Cube because it's boring, but this is the inner workings. Quantum computers can solve a lot of things today. Almost like they're always off by a little bit. They don't answer your question exactly like you asked for it, but they get pretty close in lightning speed. So there's a lot of potential. They're the first quantum computer SDKs you can actually play with in various universities. I think Big Blue has a bunch around their publicly available quantum computer that you can actually play around with. I'm not even sure if they have a Java SDK right now. But there's something you can do just looking at the potential. This has potential to actually crack all the cryptographic systems that we have employed right now. And if we're just looking maybe ten years ahead, this is another thing that we need to be on the lookout for, because that's probably going to solve problems that we think of unsolvable as of today. And yes, I'd love to have Java in ten years with the features necessary to actually implement reasonable stuff for quantum computers. Right. So Java is exciting, isn't it like there's a lot of things coming. There's a lot done today to make it fit to stand. At least today's tests tomorrow might be a challenge because there's a lot of people steering Java as of today, and they're a good team. They are doing tremendous work. The one reason for the accelerated release cycle that Java has lately is actually to be more open and more flexible when it comes to new changes. Right. So instead of waiting two years until something new comes out, you can play around with new versions of something within six months. So there's a positive side. It's not only all bad, and we have to learn something new every six months, but ultimately there will be a lot more change coming going forward, and it's pretty open as of today. And I think what I value the most and the teams working on Java as of today do probably also value that a lot. There's a lot of feedback request. So if you are actively engaged around that technology, you should definitely reach out to the Java teams. They have a Buck tracker. They are open for feedback there's. Brian Gutz is on Twitter. They are having all the open JDK mailing lists where you can contribute and ask your questions. I think it's not a hostile environment in no way even beginners are treated fairly well. Ultimately, it is open source, something that we all should embrace and also considering giving back at that point. So what happens if we don't change? We die out. Right? What if we don't change at all and something magically happens? This is what my oldest one likes to think about. Unicorns. I can promise you one thing that's not going to happen. And she's not a philosopher, but she's getting there. Wonder where she might that have from. So yeah, there'll be a lot of change. There'll be quick changes coming. And I think if we all contribute and make these changes effectively, we can all live with Java and our beloved Love programming language for a couple of more years. So thank you. Thanks for your time being here. I'll be around for a little. So if you have questions, just feel free to bug me. Hi. I had a question about productivity developer productivity, like ten years ago or when Java picked up and stuff. I noticed a massive improvement in my productivity compared to C Plus Plus or other languages today. I feel like if you have to do a small task or small application, you're better of doing it in Python or even in Java. Maybe use, I don't know, Kotlin or something else. So it seems like even programmer productivity is lacking somehow, and it hasn't stayed up at the time. That depends on your perspective for sure. I personally think like following Java literally from one to where we are. As of today. I think the productivity improvements over time are pretty clear without question. Is it the right language for simple and small tasks? Probably not. So here's something that I maybe even deliberately haven't included in that talk. What definitely also is going to influence our industry going forward. Is that the solution space broadens up a lot. So we will never be in the luxurious position ever again to just have a platform standard decision being made by a Fortune 500 and all the consultancies rolling in, they just need to roll with it. That's not going to happen ever again. So if you remember the Tob index all the languages going down. So I think the number of solutions will explode and even going forward. What's the standard way of putting things into production as of today containers? Right. So do operation teams care anymore about what's inside containers outside of the fact that it needs to be secure, they are no longer looking at Tar files or deployment structures that need to pass all kinds of shitty tests, what they actually are handing over container images. So if there's a Java in there, there's Python in there, that doesn't matter. So I think what I've seen over the years is the shift. Use the right tool for the right job. We've set that for ages, but right now we're at the point where we can, like for the first time ever, really employ that directive effectively because we don't have to fight some like central it guys anymore. So yeah, is Java the right job the right tool for every job? No, it's not. No, it has advantages. Clear advantages when it comes to teams, to scaling, to knowledge sharing, to existing knowledge, to quality insurance tools. Just think about PMD for JavaScript. Let me know when it comes out. Just think about that for Python like you don't even have any kind of software metrics. Is Python the right language to build a reasonably sized enterprise application? No, it's not. So yes, we will have a lot more tools. Java, in particular, made a great leap forward in developer productivity tooling around. Java became a lot more handy, a lot more helpful. We have so many good Ides with tremendous support. So it's been a vast difference from the very beginnings to where we are right now. Is this going to be more going forward? I think so. Definitely. There will be more beer and less recording later on. So bring your questions. Hi. Just had a question about applications of Java within algorithmic trading. Are you seeing a rise in the usage within that area, or are you seeing, just like, move away into Python dominating that respect? Or what's your view on this? I have no real things I can compare that to like, no real use cases or customer stories I could tell you right now. I think it's pretty clear where Java has drawbacks when it comes to these kind of tradings that are near real time. You need to have certain approaches to actually be able to serve them well and in the right way, except hassle cost. And if you guys want to chat later on, I think there are very few people using it right now because as far as I can recall, the best cases I've seen in the past have been like plain C. If you're doing low latency arbitrage, then C and FPGAs, but if you're doing medium frequency trading, then Java's fine gives you adaptability and quality assurance as well because of the tooling right tool for the right job. Do you have a piece of advice for Java practitioners at large organizations in terms of okay, suppose they're working on medium sized applications running on GE servers? What should they be tooling up on now and learning now going forward. I'm so glad you asked. Jesus forgot three slides. So this is a very old book of mine. It's a collection of patterns, ideas, best practices going forward, and I think it is dated. It has three years by now it's never been updated, but it's still out there, and I still believe it's very relevant. So especially if you're looking into modern system architectures coming from Java EE, this might be a reasonable handy tool for yourself to educate yourself a little bit about technologies and approaches. You can start argu pro or Contra microservices with your management after you've read that. So it's actually a pretty neat thing if you're asking for particular technologies to look into. I have to admit that I would probably argue in a completely different direction. So I'm personally convinced that distributed systems and clouds, as we have them today, are not the end of the rope when it comes to distributed architectures. Something I haven't touched on tonight is everything that we now start to hate, which is called serverless computing. So instead of having microservices which are reasonably small already, the serverless or function as a service kind of computing is making that even smaller. So we are seeing the pendulum going to the other side by cutting down microservices even smaller into function as a service serverless kind of like approaches. It works pretty neat from an accounting perspective, because you can literally define a lot more granular which resources are being used, which resources you actually have to pay for. So it's accounting, wet dream or whatever you want to call it. But for us as application developers, there are a couple of other things that are going to be awful because first of all, that stuff is all stateless, and we all know that no reasonable application will ever be designed that has no state. It's just not happening. So technologies that bring a reasonable amount of state back into serverless or function as a service kind of approaches are probably going to be the future. There are not many. The basic mantra will probably be message driven as the approach. That is something that people started to talk about when it comes to microservices. Already, that is a reasonable way to have distant services communicate with each other with no latency. Maybe you want to look into this. All those are free downloads like you just dump your email address into our marketing machine and you can download that thing for free. And if you're tired of like the marketing emails, which are pretty cool and from time to time, even for me, you can even opt out. No worries. This is kind of touching on the overall concepts around what it means to build a fully reactive architecture in a distributed sense. It's not all the way down to serverless, but it gives you a good hint in the right direction. I think I might have a little bit more for you in a couple of weeks when I'm actually talking about the future of serverless in terms of adding state. Jonas Bonaire, the author of this book, also had a talk at KubeCon in Barcelona a couple of weeks ago. So if you want to find his recording, I'm happy to point you to it later on. Well, thank you, Marcus. My pleasure. Almost on time. Thank you so much. You're.