Transcript
Horstmann: I'm Cay Horstmann. I'm the author of the "Core Java" book that's been around for 20-some years. It's probably what I'm best known for. That's what keeps me looking at the forefront of Java. Right now, I'm working on the Java 17 edition.
Bordet: I'm Simone. I work on the Jetty project fundamentally. I like to hack on web protocols and JVM internals and performance. I run the Java user group in my local town, Torino. We have these interactions with the Java and JVM panel, on what's new and what's coming in Java, every six months.
Features To Look Forward To In the Next Version of Java
Ruiz: What should we dream about in the next Java? What are you looking forward to?
Horstmann: For various reasons, as a user of Java, as a book author, one of the things that I'm really looking forward to, not in Java 17, which is going to be out this fall, but probably over the next three years, is what's called Project Valhalla. Where there's going to be a grand unification in the virtual machine between primitive types and classes. Where that distinction, really from the programmer's point of view is pretty artificial, ceases to exist. More than that, where one can now lay out objects flat in memory, without having to have that extra level of indirection that you right now have with every object pointer. You could have an array of 1000 points, and they're just sitting there, XY, XY, XY, in one array. All of that supposedly will be super transparent to developers. Of course, it won't be because it's built on 25 years of technology, and there'll be all sorts of little sharp edges, but they're diligently working on removing many of them. For example, you'll be able to then at some point in the future have an ArrayList of int, without having to worry how that really works internally. It'll greatly clean up a lot of the generic stuff. If you think about right now, where you have lots of specialization classes, you have an IntStream, a LongStream and a DoubleStream, instead of just having a stream of int. That is something that I very much look forward to. I think both for performance and for just cleanliness of the language, it's going to be a huge advance.
Bordet: One thing that I missed, which is admittedly, very low level, is the ability to do separate fields in memory, especially for example for queue implementation of stuff, so that you don't suffer from false sharing. So far, there has been a number of tricks in order to try to achieve that, but I think that if we can lay out objects in memory, then I can just lay out a bunch of in between Longs or whatever. Then have my spacing correctly done in a stable manner, rather than relying on HotSpot's internals or magic.
Horstmann: That's not going to come, I don't think. It's so against the spirit of Java. You're going to have to have faith in HotSpot to do those things.
Bordet: I know, but I cannot create an array of 64 Longs, and then reference only the first and then only the last.
Horstmann: You can do that. Today, people do crazy things. They will do just that and then force their entire storage into that, but that's not really Java. The finance people tell me they need to do that sometimes, but that is not where it's moving.
Bordet: I totally agree. I actually have recently started to play a little bit more with records in sealed classes. They're just awesome. You code with them so nicely, that I was actually surprised. The surprise effect is quite stunning. It's so easy, so clean. You can write a lot of code in zero time, and just reading it makes total sense. There's no hiding, very little boilerplate. I was actually pleasantly surprised of these improvements.
The Concept of Immutability
Horstmann: That's interesting that you say that, because there's been some doubt about the uptake of records. That everyone who sees records for the first time says, "This is great. I can get rid of all of my carrier classes," all of those getters and setters, but not the setters because records are immutable. You must have done it right, because you said, that's what I need, so you had no need for mutation. The worry there is that all of the people who are doing Java Beans stuff, and like employee data, and JPA, that they're going to be very disappointed when they see that, in fact, their records aren't going to do what they wanted. Of course, they could rewrite that code to be mutable. That's the direction in which of course the platform wants to drive us to. Yes, records I think are a quick win when they work.
There's been some research by some fellow at Google, who had a similar feature in a library where they have a code generator that makes record-like things. Looking at how often programmers took advantage of it, they said, records are on the order of magnitude as enum. They used to have an enum generator before enums came along, and people used a certain percentage of cases. They said, with records, it's in the same order of magnitude. It will be a nice feature, but it won't be a game changer. When you use it, it makes your code clean. You express what you want to express, and that's what the language should be all about.
Bordet: You're saying that the records were actually generated 10 times more than enums?
Horstmann: No, about as often. That's why I don't see that there's going to be a great exodus to records. I've talked to someone who's teaching this. He said, he's actually thinking of first teaching records, and then teaching classes, because records, if you think about it, are conceptually simpler. I am not really sure how comfortable people are going to feel about saying that encapsulation is an added extra. That's what he's proposing.
Ruiz: I do actually like that idea, because you start with the concept of immutability, that if you apply later on, we suffer from that, like applying that concept too late, and the problems arise.
Horstmann: No, it could be right. You have less baggage. You teach records, you teach methods, and then afterwards you get into public, private, so maybe he's onto something.
Bordet: Information hiding is the thing. Because records, actually, they are designed in a way that they exactly do zero information hiding. They don't even try. They try to be as transparent as possible with the data that they wrap.
Java 8 vs. Upgrading
Just to go back to the first question, "If you're still in Java 8, why are you not moving?" I see people saying I like number 8. That's obviously a magic answer. Then, more than that, it's like moving to 11, great, our organization's legacy limitations. However, I would like to ask these people that have limitations in their organization, whether they use some other libraries. For example, the one case that I'm always discussing when migrating out of Java 8 is, are you on an old operating system version? Meaning, you've not updated your operating system for years. Are you on Spring 2, if you're using Spring 2? If you're not on Spring 2, and you are on Spring 5, or you're in the latest patch for your operating system, why are you still on Java 8? That's the answer that I would like to get, because there are cases where you have to stay on Java 8. Definitely so.
There's another example that says Java 8, because AWS requires it or doesn't support anything else. For AWS support, that's fair. I'm not keen to judge on that in the sense that I don't know enough about the AWS platform to say why they're not supporting 11, or even more recent versions. The key point to me is, Java 17 is going to last from the OpenJDK point of view, six months, like any other release. The long term support label is not something that belongs to OpenJDK, it belongs to a vendor that says so. Fundamentally, Java 17 is not different from 16, from the OpenJDK development point of view. It is as stable as any other release.
Horstmann: That actually is something that I'm always a little bit concerned about. I think that Oracle has not done a great job with the messaging. There was just a discussion by Mark Reinhold, he said, "Yes, just put in all the stuff that you want to into 17." I think that's a mistake. If 17 gets a bunch of experimental things, then what's going to happen with them after six months? I asked that question, and I was told, yes, they're going to freeze them at that experimental state for three years, five years, whatever the term of an LTS is. I think that thing needs to be a little bit rethought. I think some of the vendors would be wise to say, of course, they would just remove the experimental things after six months or whatever. It is a complexity. We do rely on these vendors. I'm glad there are many of them now. At first, it looked like it was maybe only Oracle and one other. Now we have an embarrassment of riches there, of vendors who are willing to support these releases for a long time, and oftentimes at no cost, and for longer than three years. We can't complain there. The process, you would think that after all these years, should be smooth, but I think it could be better defined. I think we need the LTS releases.
Bordet: At the OpenJDK level, rather than at the vendor level.
Horstmann: That would be better if there was a recognition at the OpenJDK level, in my opinion, that those should be qualitatively different. Right now, that is not the case. We're going to have to see what the various vendors do to make better sense out of that. We've never really been in that situation before. Now with 11, ok. Java 17 is the first one that comes in this rapid train. What I would like to see is an LTS version of 17 minus the experimental features. I don't think there's anything that would stop a vendor from doing that, because it seemed to me crazy to backport for three or five years into something that no one uses. That's not of anyone's interest. If I was King, I would say, 5 out of 6 times, Oracle can put in what they want. The 6 out of the 6 times they should think about stability.
Bordet: That's fair. Maybe it's a proposal that can be attempted and see, would that apply? It doesn't seem too out of the world.
Ruiz: If you really want the feedback, it can happen in different releases, not precisely an LTS. I'm with you there. Because the whole point is to freeze it to have long term support. You don't want to have things to try out there.
Bordet: Even though it's the usual process where, for example, we have stumbled upon a MethodHandle bug that was introduced in Java 14, and that broke a number of tests that we had in Jetty for implementing WebSocket. The bug was fixed in Java 16. It took two major versions of Java to be fixed. It wasn't an easy bug. It was reported by us, and then they were working on it. It was not fixed, and they had to go through a lengthy process of evaluating the bug and finding the right solution. That took a year. Right now we have tests that are disabled. What if something like that happened in Java 17? It can happen, but that's one more reason to me to try to stay up to date, as much as possible.
Horstmann: Totally. Anything can happen. Of course, a bad bug could be introduced in 17, presumably, then there would be an extra effort to deal with it. Look at the bright side. There was a bug in 14, and it was fixed in 16. Really, no one, except you and me care about 14 and 16. No one's running in production, I would imagine. The system works.
Bordet: Unless we get the bug in 17, and then now we have to wait for 19 to get it fixed.
Horstmann: There's now a 5 in 6 chance that that doesn't happen, but it was there before. I think having these frequent releases is a win. One has to realize, who are the audience for those releases? You are the audience for those releases, and not everyone here wants to put this in production. Be grateful the frequent releases are there. Understand what they're there for. I think that's a positive. It's just, the fine points have to be worked out. That to me means that an LTS should have more special status. Here's the other thing, this couldn't have a better version number, really, 11, 17, 23?
Bordet: They're almost all primes, so don't worry.
Horstmann: No, they can't be all primes. It's an arithmetic sequence.
The Cost of Upgrading
Bordet: Another comment here, that is very laconic, is cost. What does it cost you to update to the latest Spring release, to the latest version of all the libraries that you use? For example, if you use Tomcat, or Jetty, or Undertow, or JBoss, eventually you have to upgrade to fix bugs, or to be on the latest one, for example, because of security issues. That comes, of course, with a cost. The same goes with the JDK, and staying on 8 rather than moving to a more recent version, has the same cost than pretty much everything else. The downside of this is, you stay on Java 8, and what happens is that you accumulate technical debt, because eventually you have to pay a larger cost when you upgrade from 8 to 17, or to a later version. Not only that, it is that, because you've been out of the market for years, you're not aware that now you can do text blocks, advanced instance of syntax, that you can use records in sealed classes. Isn't that putting the company that is keeping things Java 8 out of the market, especially for people that work there, are they going out of the market? Don't they fear this, to become somehow an old company, where people are now really, "We're still in Java 8, we could use 17 but we can't, we're now running out of market? I'm going to search for a new job." Is it something that maybe scares people? Are you worried about this or totally not?
The Fragmentation in Update Releases for Java 9 and 11
Ruiz: An 11 or 9 update release most likely will contain different patches, if you get it from Oracle, AdoptOpenJDK, Corretto, and Azul. How worried are you about this fragmentation?
Bordet: I can answer, immediately, because that was a question that I asked, at the very beginning, when OpenJDK actually became open sourced. I asked exactly this question. I was dismissed with, don't worry. At the time, the concept of a GA label that was applied to OpenJDK was not even in the picture. People will say, we cut a certain Git commit, and then that's the release, and we're good. Then people started adding vendors, and adding features, or getting a different Git commit and everything. Said, now how do I know what version of the JDK I'm running?
At the very beginning there was this incident with Debian that downported back to 9, some feature of 10. Then the JVM was actually installing as JDK 9, but if you were doing Java minus version, it was printing out Java 10. That was a royal mess. That was an obvious mistake that happened in the past. It was scaring people out. It's like, if I download this version from a trusted repository, switch the Debian one, but I get something that is in the middle of nowhere, it didn't pass the TCK and whatnot, what am I running? Am I running something that is trusted in any way, shape, or form? That raised a big question. Vendors don't answer these questions. My take is I stick with the AdoptOpenJDK, because I trust that they take the GA tag on the OpenJDK GitHub, and they build that. That's it. That's the one thing that I trust. I don't use vendors. I could trust vendors. They need to be crystal clear to me on this. They should be able to say, here's release notes. We have taken the code from this tag in OpenJDK, which is a public one. We have applied these patches, and that's what you're running. We'll see.
Horstmann: It is going to get complex. I absolutely agree. AdoptOpenJDK, or Adoptium, as it's soon going to be called, is the rational place to go. Or you could pay Oracle and you know that you're getting Oracle's. With these others, I'm not really sure, what's my motivation as I'm going to go to Zulu. With Corretto for example, if I run something inside AWS, there's a good chance that I'm just getting it, or that's the easiest to get them. Of course, sure, I could find an image that doesn't have it. It's going to make your life much harder as a library provider, who may well get subtle bugs because of whatever.
Ruiz: The fact that it passes the TCK doesn't mean that they follow the same implementation from some libraries. There are differences. Sometimes they are trying to improve their performance in some particular vendors like Corretto.
Bordet: That's where the OpenJDK encapsulation, like the strong encapsulation that is coming with 16 and then 17, it is going to somehow help with this because libraries will not be able to play too much with the JDK internals. They have restricted their ability to play with the JDK only through public APIs. That's a good thing. It will eventually avoid that people will leverage implementation differences.
Horstmann: That may be another good reason to move forward.
Bordet: For example, we just moved the Jetty build from 15 to 16. Of course, we had, I think, 20 test failures or probably 40 or something around there. The reason is that we are integrating with a library that plays badly with the JDK, doing deep reflection on JDK classes. Of course, the JDK default for Java 16 is now deny, so don't do that. We had 40 test failures just because of that. Now we have to add a bunch of add-opens waiting for this library to update and remove those hacks.
Horstmann: That friction is going to continue, that probably no one's going to want to move to 17 for production in August. Java 11 seems a good point to be at now.
The Relevant User-facing Benefits of Java 11, Compared to Java 8
Ruiz: Does Java 11 bring relevant user-facing benefits over Java 8, like big performance improvements? This is because people are using cloud based applications. What could be the highlight, some of the most appealing reasons for upgrading that can be justified for the customers?
Bordet: The first time that I deployed Jetty to serve our own website, and I moved from 8 to 9, not even 11, the startup time for Jetty was about 30 seconds, with Java 8 for our own website, which is super small, actually, forwards the call to WordPress. With Java 9, it went back to 4, 5 seconds, so much so that the first time that I actually ran Jetty on the new website, and it was like Jetty start, Enter, and then boom. Then I was like, there was an error. I was thinking, there was an error because it started too fast. There are performance improvements on that, that can save you money, especially when you run on the cloud, because it will consume less CPU. It will load faster, and all that magic thing. It's not only about the big performance improvement or stuff. Right now, I think the onus is on you to justify why you want to stay on 8, when you know that the platform is going to improve and be a lot better every single major release. Why do you want to stay on 8? For example, I'm upgrading Spring from 4 to 5. Why is that? Because they streamline things. They have performance improvement with that. Why are you not doing this for Java? There's no explanation to me, just do it.
Horstmann: Let me also actually echo your technical debt issue, because moving from 8 to 11, that's when you climb the module hurdle the first time. If you have to climb from 8 to 17, that might be a pretty steep jump, because 8 to 11 is still fairly permissive. When you're running into module issues, you get warnings, but you can react to them. If you go from 8 to 17, it's all going to be close up to you and you're going to have a heck of a time. I think that since, at some point, one has to pay that technical debt, you might as well do it in reasonable chunks.
Bordet: I totally agree with you, that the big hurdle is, in my opinion, 8 to more than 8, wherever you go. Now the common case is 8 to 11. That's a big jump. You don't want to accumulate debt on that jump. Once you are on 11, then all the other updates going to whatever future version, is very smooth in our experience. With Java 16, now we have added this encapsulation problem. That was announced. It was coming. It came. It's here. Go and fix it in the libraries that still do nasty stuff with JDK internals. Once you get the libraries done, then you're good to go. Move forward.
The Real Hacks of Upgrading
Ruiz: Actually, we had this session with Marc and he was talking about, in critical production systems, how do you upgrade? Because obviously, there is always a compelling reason to upgrade. What could you tell us about this discussion about the real hacks of upgrading?
Hoffmann: I can only second what was already mentioned here, and maybe the commercial side of the thing is also important for the enterprises that cannot afford to update. Especially if you're before Java 8, you're running on an unsupported version, you won't get updates for that. If there's any issue, if you need to replace your operating system one day and buy new machines, you may not have a Java version you can even install on those machines. Currently, we have a strong trend towards ARM architectures. The cloud providers probably, due to energy efficiency, will move more to ARM. Now we get new operating systems, which are not placed on Intel. How do you get a Java 7 VM for that? Probably you can buy them maybe at Oracle also for tons of money, but you won't get that for free. You can think maybe you better invest the money in moving to a newer Java version and have also the new platform supported. Maybe your developers will force you because they cannot use their shiny new MacBooks anymore with the old Java versions.
Bordet: For example, one of the reasons that I get told with not updating is, the production side of things is handled by a different group. They don't want to update because they caused things like the infamous sysops. Their argument is, I can get free updates, in the sense that they don't have to do anything for the operating system, because for example, if you have Ubuntu, there is a cron job every day. It pings the repositories and says, is there any update? Then prompts you with the update. You can automate everything, and you're good to go. We cannot do this with Java. Can you not, really? Because there are tools and everything that can actually query repositories for Java and download the version and the vendor that you would like to install in your system. Keeping the whole thing up to date.
I'm not saying, for example, going from 16 to 17 in production without testing before, but going from 16.00 to 16.01, when the usual three months security patches come in. Why not? We do this all the time in our phones, in downloading the latest patches for Android and whatnot. Same for Spring and Jetty, we have recently released a couple of releases because of security advisories that were filed against us. We asked people, please do upgrade. We tell the Spring guys who depend on Jetty, please use the latest version of Jetty because there is a security issue, and so on. I think it's more like a mental process. You have to have a process in your company to upgrade everything from the operating system up to your library. Just because JDK 8 works, it's not a good reason to stay there, and update all the rest. It's like, why do I still have this old thing here?
Hoffmann: Absolutely. You really should get used to updating your production systems. As a friend of mine always tells us, so if it hurts do it more often.
Ruiz: There are some performance improvement like compact strings that you don't have to do anything and you will benefit. There are some times that you have to invest into changing your code for using the features, but you still benefit. You get the feedback of what is going to be a painful situation in the near future, that it has to happen because the libraries will probably want to upgrade, or new tools wouldn't want to start with an old version of Java. There's always a compelling reason to migrate or to upgrade.
Bordet: There have been a few comments here that say, no, we use WebLogic. We have, for example, a certification constraint to stay on a very specific Java version, because that's the Java version that WebLogic is certified against. That's a very good reason, and it's an economical reason. Now you need to sit down and say, how long am I staying here? Developing in Java 17 is a whole lot better. Your developers will be so much happier. You have to put on the weighing scale, fundamentally, what is important? What are the consequences of staying on an old platform, old WebLogic, and everything, and try to move away from that?
There are companies, for example, that help you to move away from these old scenarios. Maybe the cost to get help to move away from an old WebLogic version to where maybe you don't even use EJBs, but it's just a web application inside WebLogic, then there are companies that help you out. Maybe paying those companies to help you move away from WebLogic, cost you a lot less than a single year of WebLogic thing.
It's always a tradeoff. Don't stay on Java 8, just because you don't know, or something like that. If you have a very good reason, like the WebLogic case, ok. If you don't, then just go for the upgrade.
Horstmann: The developers will thank you.
Experience with Java Modules
Ruiz: What's your experience with modules? Like records now, back some years ago, modules was the key word. It has passed enough years, so module should have been adopted. They didn't. What do you think happened?
Horstmann: I said, I'll start believing in modules for everyone. Modules have an undeniable advantage for Oracle, for the architecture of the JVM, and the JDK itself. They're allowing this encapsulation that we badly need. What about other people? I said, I'll believe that modules will be interesting for general programmers, when I see the Java EE web servers being implemented with Java platform modules. What did Oracle do? They immediately ditched the Java EE effort, so they didn't have to do it. These are there for large scale projects, for big systems. I have not personally seen a big system that has a modular architecture. I've seen some libraries and components that have been modularized, just in case someone wants to use them as modules. I've not seen a big system.
Hoffmann: I've never seen a big system that uses a Java module system, but I've seen a lot of big systems which uses other modularization systems that have been established over the years. The problem with modules is it basically competes with systems like OSGi or other component systems, which have been around for years. Maybe it's a bit too late in the game to really get that adopted, and maybe some major frameworks have to jump on the modules, pass the module string to make them successful.
See more presentations with transcripts
