Foojay Podcast #68: Welcome to OpenJDK (Java) 24

Transcript

Automatically generated from the audio, so it can contain errors in names and technical terms. Suggest a correction.

[0:00] March 18th of 2025 brings us Java 24 let’s find out what’s included welcome to the FJ podcast all your news about OpenJDK every 6 months I serve you a podcast about the new Java version I’m happy to have my regular guest Simon Ritter Deputy CTO of azul also known as speak Java on all social media he is part of the OpenJDK vulnerability group gcp executive committee and expert group for the Java SE specification request so he can share with us a lot of backside info today we are joined by Hano embre a Java developer by day and musician by night he publishes a post on Foojay with all the details of every new Java release and also for Java 24 he prepared a long description with all the new features that are included in this new Java version thanks Hano and Simon for joining we have a new Java version to celebrate and it has 24 jeets Java enhancement proposals so 24 jebs in release 24 Simon were you in the meeting where they decided to have 24 jebs no no but I mean this is a good point about the way that jeets work and the fact that we have the six-month release Cadence now it just randomly

[1:25] You sometimes you will get like maybe six or seven jeets sometimes you get 20 4 jeets it all depends on when those jeets actually come to a point where they’re ready for inclusion and I think this demonstrates the power of how the whole jet process and the six-month release Cadence works but I guess they pushed a few extra in or they left one out to stick to 24 I don’t I’m not sure about that the reason I say that is because obviously 25 is going to be the next long-term support release now I know that if you ask the OpenJDK People they’ll say oh no we don’t consider long terms of Port releases in terms of when we put features in but I think that there probably is a little bit of shall we get things in for JDK 25 because it is going to be a long-term support release but 24 being a not a long-term support release is just you know a feature release as they call it so Han you prepared a Long blog post for Foojay with everything which is included I was trying to find myself some structure in this 24 jebs but actually you already did that and you grou them a bit by by topic I think that’s

[2:33] That’s a good approach of how we can go through the list of these jeets and maybe I don’t think we need to discuss them all 24 in detail but there are five jeets which are related to hotspots and the garbage collector can you summarize them a bit maybe H you can start with what’s most important for you in this topic when I researched the different jebs and when I was trying to get a nice reading article out of it I quickly discovered that well a lot of changes are under the hood this time right so a lot of features are related to performance improvements or decreasing the size of a build JDK when that you can create using jlink for example removals deprecations so like all kinds of work that is being done to further stabilize the platform and make it future proof I guess and the changes in hotspot really also make me think of that direction so for example there are a few garbage collection expansions that have been done for example in the Shen andola garbage collector that now also supports a generational mode which we probably already know from G1 and the Z

[4:00] Garbage collector as well because that one also got generational mode in one of the more more recent versions of java there’s a JP about late barrier expansion which is kind of technical I had to get deep into the garbage collection internals to really understand that one and then I try to you know write about it in the article that you mentioned but late barrier expansion is effectively an optimization of the C2 compiler one of the just in time time compilers that is used by the hotspot JPM and the fact that these barriers are placed later in the process means that it is more optimal and can potentially reduce the overhead of the Just in Time compilation process and another feature that I really liked because it’s one of the first that comes out of project Leiden is ahead of time class loading and linking I’m excited about that one because I’ve been following project Leiden for some time now and I think this is one of the first features that is published from that one means that you effectively you can start up a JVM and warm it up so to say so to say

[5:12] And save the state of the warmed up JVM to disk and then when you start the JVM up again you can refer to that saved file and the entire warmed up JVM will be loaded much faster than before I see you agree Simon with that one is an important one yes yeah I mean as Hano says there there’s several things under the covers that we’re seeing with JDK 24 the project Leiden is an interesting one because you know the first part of that is about ahead of time class linking and verification so that that’s the sort of starting point is that we can record the data associated with classes once they’ve been loaded and initialized meaning that when we start out the application again we don’t have to go through the same process and that will save time but that that’s the first step in terms of project lien next we’ll be looking at you know using the saved jit compilation data so that we can avoid the overhead of having to figure out which methods are used frequently then compiling them with C1 recompiling the C2 and doing that so funny enough this is very interesting because it’s exactly the same as what we

[6:22] Do on our platform Prime product in terms of ready now because we we’ve already done all of this so we did you know initialize all the classes and linking all the classes and we’ve done caching of the compiled code and things like that so it’s nice to see open J K actually catching up with on this particular one yeah so I mean there’s obviously couple of other ones that are under the covers in terms of like Improvement of the garbage collection one I saw as well was shrinking the object header from down to 64 bits typically it’s 96 to 128 bits and you think to yourself okay so you know a few bits here a few bits there does it really make that much difference but when you look at the reality of objects that you create in the Heap most of them are very small so the impact of shrinking the object header like that can have a as they claim in the jet it’s sort of 10 to 20% reduction in the amount of space that’s required for the Heap and that will be significant when you’re especially when you’re running in small containers where you’ve got constrained resources that could be something that

[7:28] Really helps that type of application another one related to the hotspot is synchronized virtual threats without pinning JEP 491 that was a problem related to Virtual threats which were introduced in 21 right was this something wrong with virtual threads not wrong with them it was a limitation that was applied to Virtual threads so if you look at the way that virtual threads work it’s it’s the idea of being able to share what’s called a platform thread or a carrier thread amongst a number of threads at the Java level so you’re effectively mapping multiple Java threads into a single operating system thread and that works very well in certain types of application where you’ve got thread per request and most of the time the thread is blocking on things like IO so it’s it’s spending most of its time sleep but the limitation that they had was if you blocked within a synchronized method or a synchronized block then you still couldn’t switch to a different JV of a thread so virtual thread at that point so in those types of situations it was a limitation what they’ve done now

[8:37] Is to rework the way that the monitor is used in a basically the synchronized keyword so that it’s up to the JVM and the Java thread to be able to control that use of the Monitor and that way the monitor can be released and reacquired so that you can switch even when you’re in a synchronized block the first time I encountered the fact that you know the virtual threat got pinned to these synchronized blocks I was kind of confused and then I researched it a bit and then it kind of made sense right before Java 24 a monitor could only be held by a platform threat and it also means that if virtual threat number one enters a synchronized blocks block and then is blocked it can get swapped out by virtual threat number two now imagine that both virtual threads are actually running on the same platform threat that means that the second virtual threat can actually enter the synchronized Block in the middle of the block so that’s a major security risk of course not to mention the concurrency things that could go wrong there I do like the fact that this is now solved because

[9:46] People were switching to other locking mechanisms right the java. ut. concurrent locks did not pin virtual threads and I don’t think that should be a reason to switch to other locking mechanisms I think the reasons that we are used to should still apply even on recent Java version so I like the fact that virtual threats has overcome the limitation here concy is already hard enough yeah it’s great for all those people still using the vector class so they got synchronized methods should there be anybody who’s doing that if they stop stop bad idea okay there are also three jeets related to security libraries so already thinking about Quantum solutions that that’s passwords can get hacked and easier with Quantum systems is that already one of the goals I think it is so I’m not the greatest expert on these security algorithms I mean who is I read into them and I was like wow this is some heavy stuff but on the other hand I do like the fact that the Java platform is thinking of you know advancements in this case Quantum Computing field to make

[11:06] Sure that the platform doesn’t become extra susceptible to practical Quantum Computing attacks right and the Java platform has always contained certain security algorithms probably we all recognize Diffy Helman or RSA right and if we keep on using those algorithms in an age where Quantum Computing advancements are progressing we really want some more modern algorithms to be supported so that’s the reason that a few Quantum resistant algorithms have now been added I’ve got to say I just love that the whole term quantum resistant sounds like something out of you know like the Mel but yeah it’s it’s great that we are I people are warning for that the fact that quantum computers will make it a lot easier to break encryption and it’s great to see that although that problem is not that critical yet we already see in Java improvements coming to stay ahead of this problem I do tend to trust the Java platform a bit more here right I trusted it already I mean not to say anything bad about that but the fact that one of my favorite programming language is ahead of the

[12:29] Curve here or at least that’s what it looks like to me I really like that and you know it can help us strust the platform for their future as well right it it’s it’s still a very very good choice for new software projects because of stuff like this yeah no I mean I agree that you know the forward-looking nature of this and figuring out what needs to be done before it becomes an issue is a very sensible thing to do so yeah keeping Java as secure as possible okay you had one JEP H that you had a separate title for tools is JEP 493 linking runtime images without J mods what’s the goal of this JP the jlink tool that is part of the Java platform can you can use that to build a custom JDK that only has the modules that you need which is the goal to run with jdks that are a bit smaller right and the goal of this is actually to further reduce the size of the your custom buil JDK and the way it works is traditionally the jlink tool uses the J mod files that are in the JDK to create a custom runtime image but every JDK always also contains like a pre-build runtime image

[13:49] And there is some duplication there right so the stuff that is in the J mod files is also in the runtime image that is already present in the JDK so in Java 24 the tool is extended so that you can use the runtime image that’s already there and extract the resources that you need to build your own custom runtime image and that means that you can further reduce your jdks total size and well in the context of cloud environments you know where you copy your container images quite a lot this can further improve you know performance and the time you have to wait for downloading and uploading and that kind of stuff indirectly it’s also related a bit to this speed up of starting up your application so it makes it all more eco-friendly you don’t need that much storage for your application you don’t need that much warmup so again Evolutions within Java in the goal of more efficient systems correct right I I’m not sure it’s it’s that much related to performance benefits but at least you could say that the platform is getting more efficient here right efficiently using the available

[15:05] Bandwidth for example and what I like the best about this feature is again the context that it is set in right so the Java language designers they recognize that the way that Java is used in the cloud asks for a more efficient use of bandwidth yes because I mean this was one of the big goals of when they brought that in jdk9 was reducing the size of the runtime and if you look at a sort of a standard-ish kind of JDK it’s about 3 350 megabytes in sight which might not sound big by you know modern standards because you know we deal with gigabytes and terabytes and even petabytes but when you’re dealing with containers which have got constrained resources and so on and it’s also the whole idea of security as part of the issue that we’re solving you if you use jlink and you strip down to the very very basic sort of fundamentals it goes down to about 30 megabytes so you’re talking in order of magnitude in reduction and that’s really just for you know the having Java do base as the module but once you start adding more things to that it starts getting bigger

[16:14] Again and the whole idea of this removing the jod files is to then try and shrink it a little bit further so it’s it’s definitely a good idea that’s a nice topic that you mentioned is also security so the less content within your run time the less errors there can be in there so that’s maybe also a good idea to use jlink and reduce your runtime is yeah you make it more secure because you remove a lot of things you don’t use anyhow it’s it’s called the attack surface so you’re reducing the attack surface of your application then we have a lot of re previews and finalizations so this is how these Japs work so they have Generations or third preview second preview we even have let N incubator n in nin incubator yes are these now all being prepared to be ready for that long-term support I cannot call long-term support version 25 in September is that a bit the goal that this is the final review and then we will see a lot of these in 25 I think some of them you will the Vector API which is the one that’s now in its ninth incubator iteration no that’s not going to be final in I can

[17:36] Pretty much guarantee it won’t be final in JDK 25 the reason I say that is because the designers or architects of the OpenJDK have already said with the vector API because it’s a sort of part of a larger project Valhalla they don’t want to make it final until they’ve delivered more of Valhalla into OpenJDK at that point then it will become final so there’s still a lot of work going on in the background on Valhalla until we get that we won’t see Vector API being final it’s interesting to see though that in even in the ninth iteration they actually made quite a few changes so it isn’t like it’s just being you know sort of moved forward as a new incubator without making any changes okay maybe we can go through the list and see if there’s what’s most notable about these so JEP 48 four is class file API so that’s a new one which is finalized I think it’s now included as standard feature what’s important about this new API depends on your point of view because because a class file API is more about people who write code that actually deals with stuff in

[18:50] The JDK itself it’s not so much application Level API so that one to me is less interesting but only from the point of view that I tend to write applications rather than code that interacts with the compiler and things like that so maybe it’s more important like Frameworks like spring Frameworks who load class files those will use this new API yeah okay good next one 485 stream gathers is also finalized what changed there compared to Java 23 absolutely nothing changed the status has been changed to final but if you missed it in Java 20 3 well stream gatherers are a way to define custom intermediate operations on your Java streams I think it’s it’s it’s a lot like the way that we can already write custom terminal operations with the collector of API there I regularly te Teach Java courses and I ask my students to you know Implement their own filter based on the stream gather API and they’re like what’s the point the filter operation is just already there and I said yeah you have to know the stre together AP so MH I like from a teacher perspective I like

[20:02] It very much yeah as you say it’s it’s it’s an extension so that intermediate operations you can Define your own one in the same way we do with collector so that that’s gives you that extra flexibility I must admit that when I kind of looked at the examples that they provide for that certainly something I’ve I’ve not found that I’ve haven’t been able to use the right intermediate operation in the past that’s not to say that you know because maybe my code is not really complicated I think giving that flexibility to developers is great because then if they do want to Define their own intermediate operation they can do that probably not many people will in the end but it’s great to have it there I had a few students in my class who were used to culin programming and they really missed the distinct bu operation okay right actually coincidentally the one that is also use as an example in the jet so then I could convince them that you know Java does support that if you write your own gather there right it does support it from 24 on I think 22 if you if you’re comfortable

[21:10] Leaving the preview flag on of course which we already mentioned a few times I think in the past you should not do that in production prob do that in production so now if you switch to 24 you can do it the next one is the fourth preview of scoped values again did something change there a tiny thing changed there because the like Jeb says the entire API is now fluent so that means that if you want to use a scoped value you can start using the scope by calling scoped value. whereare and in Java 23 there were a few methods they were called call Weare or run Weare which were just shortcuts for scope f.w. run or do Co and well the exact same mechanisms are now only U reachable using this fluent API mhm but apart from that it’s the same as before and for preview again will it become available next time I think that one might become Final in JDK 25 but yeah that’s that’s my prediction I don’t have any inside information the next one 488 primitive types in patterns instant of instance off and switch again second preview what will we change there again absolutely nothing just a second preview

[22:28] Stage to gather more feedback is it that not strange that there is a second preview was there not enough feedback to finalize this that’s a good question I mean I don’t know enough about how because individual Jets obviously have different groups of people involved in them and maybe they felt that it needed a little bit longer for people to evaluate it before they made it final you can give us some insights in how these jeets work so there’s a group of people who think yeah this is a good idea we should add this to Java so they work with the Jeb who then decides when something is final enough is that the same group or do they have to talk to The Architects of java to decide what is mature enough to include my understanding is that obviously there will be somebody who submits the Jeet maybe more than one person who submits the Jeet and then there will people who actually work on that once the people who submitted the jet feel that it has got to a point where it’s ready for inclusion then they would then discuss that there’s a whole process that different stages that

[23:33] That jeets go through and so it would have to be referred back to the Architects so people like Brian gz and Mark Reinhold who would then say okay yes you know we’re happy with that so we’ll make it fine the vector API you already mentioned that one the next one is 492 flexible Constructor bodies so that’s placing the super on a different level and do some checks before you construct an object what the important change changes there I don’t think there were in this case no it exist to gather more feedback so in this case they decided that they wanted more feedback from the users in the third preview stage we have also 494 module import declarations what will this bring to the new Java modu import declarations were introduced in Java 23 so this is the second preview stage now and it is like an alternative to many import statements from the same package right so you can replace like if you’ve got eight or nine import statements from the state package you can replace it by a single module import declaration it’s along the ideas of you know introducing wild cards for you know

[24:40] Package Imports it just simplifies things a bit in terms of how you can do that goal again to have some more developer productivity less code less things to review less things to read yeah yeah yeah which we love because the less we have to read the less we can do wrong you have to be careful because you don’t want to sort of go too far in the opposite direction which is where you then start introducing ambiguity and it’s it’s hard to see which things are actually being imported but in this case I it’s fine Jeb 495 simple source files and instance main methods can you explain what this is about H this Jeb exists to make sure that people that learn Java for the very first time are not overwhelmed you know by the mysterious incantations MH public setic for being string area arguments get up to speed with a Java file easily just by typing a void main so the JEP introduces the possibility that a Java file can just contain a void main what I like about this feature is the fact that it actually works together with the one that we just discussed modu imput Port declarations because in order

[25:49] To shorten a basic Java file here that also means that the print line statements don’t need Imports anymore because well if you have to teach a beginning Java developer what system. out is well then you’ve lost them already or I can imagine you’ve lost them there in your train of thought and that also means that the java. base module is now automatically imported using the feature module import declarations so you can use a few basic apis without using Imports at all which is also again a more complex construct in the language that you don’t have to teach developers who are just starting out so that also means that the entire collection API for example is available to use in these simple source files without having to worry about Imports I’ve always struggled a little bit with this particular feature because I get the idea that you want to reduce the sort of hurdle that people have to go through in order to write their very first Joba program so the sort of hello world program we eliminate a lot of that ceremony but the problem is that as soon as you start going

[26:58] Beyond Hello World you then do need to understand the structure of classes and how that all works but the one thing I do like about this is that elimination of system.out.print line and just print line because you know that that’s what we should have had basically from the beginning I think that’s yeah one of the most clear differences now if you go to teach a very first file and I know Simon you’re not a big fan of these changes we discussed this in the previous podcast with the Java releases but h do a lot of trainings are you giving trainings to people who are new to Java sometimes I teach groups of students that haven’t seen a single line of java code before and I don’t think they will consider leaving Java behind just because of these four mysterious words but I do find that it helps in them accepting to learn this language because you know as soon as I explain that this is the basic construct of starting a Java process they’ll immediately tell me how much easier this is in other languages right and the group will start talking about let’s let’s learn cotlin Let’s Learn

[28:10] Python or something and I I’m there to teach them Java so I don’t want these conversations bringing up so it does provide a more positive attitude in the classroom and yeah again as a teacher I really like that though I think I agree with Simon so imagine you start your Java project with one of these simple source files do you still expect it to be present in your project three months in right I don’t I don’t really see that happening I think this is in combination with jbang where you then also simple simply can add a dependency I think this for education and I really like it to I create these examples for Pi4J where you have interaction with electronics I really like that you can have one single file with some dependencies to EXP explain a very simple principle but yeah as soon as you create an application yet then you have to take that step I think I need to make it clear though I’m I’m I’m all in favor of making easier for people to start learning Java I don’t want to try and stop that kind of activity so it’s just for me personally I see that you know once you move

[29:19] Beyond that s very very basic program you do still have to learn about what does public static void main mean and things like that so mhm we have one final JEP in the list of repreviews and finalizations and that’s structured concurrency what does this JEP try to solve this is an interesting one because the forth prr doesn’t contain any any additions whatsoever but that doesn’t mean that no changes are in planned right because I know for a fact that a few changes are planned so to get back to the your question structure congruency is a way to enable Jai developers to Express a hierarchy between different concurrent tasks right so if you’re if you’re starting up multiple threats in your code you could use the structed concurrency API to express a certain relationship between your tasks so imagine you have a final result and it is it can only be constructed if you’ve got three sub results if you have access to three sub results then you could spawn off a few threat and within a structured concurrency block wait for the three threats to finish and then finally you have your

[30:35] Final result and it can be constructed and one of the benefits of using this API is when one of these subtasks fail then the other one could get cancelled while they’re still running right because you already know that you’re not going to be able to construct your final result because you’re depending on one of these sub results or the other way around when you’re spawning off a few subtask and you don’t care which one of them succeeds as long as one of them succeeds then you can also cancel the work that is still running once one of your subtasks has successfully returned so those are a few of the behaviors that you can create using structured concurrency now to get back to my point about the preview status here nothing was changed compared to Java 23 but there are a few changes that are written in a Jet draft about opening structure Tas copes and so the API is probably going to change in a future Java version the structure Tas cope Constructors that we now have to use will probably be replaced by Factory method called open and it will be a bit more more extendable that you can

[31:47] Define your own operations so you can Define your own behavior when the scope has to shut down and when it Returns the result I actually spoke to Nikolai parlock from Oracle about it because I have a talk about this topic and I wanted to know whether it would be in Java 24 or not and if it would still make sense to talk about the old way that the API worked and he said we were trying to get it into 24 but we didn’t make the deadline right so then they say they said let’s just leave it like like this and work on the new API for the next Java version so that also means that it will probably be previewed again because there are significant changes and I don’t expect them to make it final I think they still want some feedback on the changes yeah I think this is really interesting because you know we we’re at JDK 24 and we’re still adding new ways of improving How We Do cooperating multi-threaded applications you know if you think about the history of java Java 1.0 had the idea of multi-threading in it right from the very beginning but of course writing cooperating

[32:58] Multi-threaded applications is notoriously difficult and the functionality we had at the beginning was so basic and then we had the introduction in what was it Java five of the concurrency utilities which gave us all the sorts of things like semaphores and mutexes and stuff like that jdk7 gave us the fork join framework jdk8 gave us streams and parallel streams and then was JDK 21 we got virtual threads so we and plus structur concurrency and you know things like that so we’re continually trying to make life easier for developers when they’re trying to do these hard tasks this also relieves a bit the danger of using these preview features as you said they are not finalized so they can change and this is now an example of one that will change because they will make the Constructor differently in the next version yeah so that means that well I hope people listen to Our advice and that they haven’t used this in production and the only that will break our well is my demo code right for my conference talk and then it’s okay I’ll just change it and then we have a few

[34:05] Jeets you group them together Hano as deprecations and restrictions that means is this cleanup that’s going on within open JD key yeah right I actually applied this grouping well I did it also because there were so many JBS here but also when I write an article about the new Java release and I send it to my colleagues they they’ll be like yeah that’s that’s very nice but what think things are actually new I mean so in the past I just listed the jebs based on their order you know the numbers that were they were giving they’re interesting enough you know if it’s your kind of thing but and they are important because yeah if you are using them you also should be aware of them like jni prepare to restrict the use of jni first what’s wrong with jni and why is it restricted I don’t think that’s necessar anything wrong with jni it you know if you want to use it there’s there’s certainly a manual right there’s a way to work with it but I don’t think the language designers intend to deprecate the API whatsoever Simon is laughing so I I’ll ask him well there’s a couple of things to

[35:18] Say here because one is that this is kind of related to project Panama is designed as a replacement for jni so we have the foreign memory and foreign function API that’s already been delivered into there so it’s trying to get people to move away from jni the reason I laugh is because I remember that when we started doing Java right in the very early days and I started using jni and it’s notoriously difficult to use J and I because you’ve got to you know create the sort of rapper classes and rapper methods and you got to find the right libraries and youve got to create the header files and all sorts of things like that and I specifically remember talking to one of the people who developed jni and I said to him you know like this is quite complicated to use he went ah yes we designed it that way we wanted to dissuade people from using it it’s like that’s not a great sort of design philosophy I don’t think but like this foreign function API makes it a lot easier so that’s a bit the IDE get people to move to the other side and I can agree I didn’t do it

[36:23] Myself but someone who cooperates in the Pi4J project he created an interaction with electronic components based on a cclass and it’s way more easier than than what we used to do with jni so yeah it’s it’s definitely a step forward yeah the one thing that I still think is missing that should be in the JDK and there’s been discussions about this but they haven’t put it in yet which is J extract and if if they put J extract into the JDK that makes the whole Panama stuff so much easier but there seems to be a reluctance to do that mhm wasn’t the problem that J extract is pretty big and makes the JDK yeah yes that that’s one of the concerns is that it’s it’s quite large and so adds to the size of the JDK but with Jade link you could remove it we already discussed security and how Java handles security way better than than other things and then also is preparing for Quantum resistance but then on the other side we have permanently dis dis abled the security manager JEP 486 is this related or is it just the security title which is causing some confusion here this

[37:37] Is one of those things where people look at that go per disable the security manager doesn’t that make it less secure but no it doesn’t the security manager was introduced very very early on in Java because Java had the whole idea of moving code around the network and executing code from potentially an untrusted source so you want to have a security manager would then limit what untrusted code could do but the problem is that’s not the way that really anybody nowadays still does Security checks for this kind of thing so there’s different ways of approaching that so they they’ve decided that they wanted to get rid of it because it was quite a big overhead in terms of the burden of Maintenance and so on having said that there are still some people who have used it for different aspects and they have hav provided direct replacement for that so some people are kind of just left with like okay you’ve got to figure out how to work around this so it’s it’s a bit of a sort of double-edged Sword so it’s not related to Security in the sense of logging in systems and stuff

[38:42] Like that it’s really related to how Java code is loaded and so it doesn’t make Java less secure that’s the important message to remember okay je 490 is zgc remove the non-generation mode so because generational mode was added why did it need to be removed then the generational mode was introduced because dividing your garbage collector process in separate generations allows you to increase the performance of your garbage collector in most Java applications there tend to be many objects that we call Young so that are not around for a long time and very few objects that are old that are around for a long time in the Heap so that also means that if you divide your garbage collector into a generational if you support a generation mode you will probably collect garbage on the young object much more frequently than on the old objects the Z garbage collector has supported this since Java 21 that also means that we’ve got some experience with using it and it well as it turned out it is a far better performance when using the generational mode this is one of the

[39:57] Things I actually find a little bit surprising because as you say you know there’s this thing called the weak generational hypothesis which is that says that most objects are very very short-lived and can be collected very quickly and that’s proved to be accurate for you know the vast majority of applications so the decision that both Shen and DOA and zgc made to go non- generational in their initial design was quite surprising to me because I would have thought that you know you would have the sort of body of evidence is that a generational collector works better than a non-generation collector but they still went down the idea of no no we won’t use generations and then they discovered funnily enough that the performance wasn’t as good as they wanted it to be so we’ll now switched to being a generational collector so yeah yeah I find this these garbage collectors so fascinating because there are different ones in OpenJDK and Azul has another one and how they work the main goal of a garbage collector is as a developer you don’t need to worry it will manage the garbage collector as it should but

[41:00] On the other hand if you know how they work and that there are different ones you can achieve more performance or a better working application Garett Grunwald has an amazing talk about this the trash talk and this really he really illustrates what Young Generation is and old generation and how these these different systems works I think the important thing is as you said there and I’ll pick up on that which is as a developer you shouldn’t think about how the garbage collectors work working so don’t try and program to work with the garbage collector because sometimes people would sort of pull objects and do things like that where it doesn’t make sense so just write your code in the best way for what you’re trying to achieve and let the garbage collector do its work the fact that we have multiple different garbage collectors within the JDK is more a reflection on there isn’t one algorithm that works perfectly for all applications so you can choose different garbage collectors and tune them in a different way for whichever workload you’re doing that said of course we have C4 in our platform Prime

[42:03] Product which is pretty much you know good for most situations but not 100% let’s jump to Jeb 498 warn upon use of memory access methods in Sun MK unsafe if I’m correct this is one of those classes or packages which was used in the 1 million row challenge that was a bit a big thing last year again one of those packages an old package it even has Sun as the package name why should we be warned if we use it like you said the package is named Sun so it has been around for quite some time I think the class was introduced back in 2002 and back then we didn’t have the module system yet so there was no way to restrict access you know to this part of the JDK and if you don’t acces like it’s the same with my kids right if I give them the tablet but I don’t restrict the time they spend on it or the apps they’ll probably find a loophole somewhere you know and they find it anyhow right and they’ll spend the entire night playing some kind of game if I didn’t restrict it enough during nighttime and the same thing happened here right so people discover this class and well more recently discovered

[43:21] That you could use it very very well to score high on the on that challenge that you refer to the methods in this class and more specifically the memory access methods they became a valuable to for Library developers that were looking for greater power or performance than what standard apis could provide well of course we don’t really like the situation so apis have emerged in the recent years to provide better alternatives to these problematic methods and the foreign function in memory API is one of them and I think far handle is the other one when you want to manipulate on heat memory in a safe way so that means that the methods that are in unsafe I think there are over 80 methods in there they are gradually they can be replaced gradually and these two apis play a huge part in that I think a few methods are still around that don’t have replacement yet but well as of java 24 in this warnings will be generated when you use them and well of course in a future release they will be restricted even more but for now we get the warnings yes this is

[44:41] One of the things that turned up in jdk9 because when we introduced project jigsaw the idea of encapsulating all the internal apis was what they really wanted to do but as Hanah says you know lots of people because they were visible people had actually used them and so there were things like you know spring Bo framework and spring had all used the sun Miss gun safe and suddenly it was like well yeah we can’t just turn off access to that it’s going to break lots of applications so they left the capability to access these things even though they tried to turn off as much of the internal apis as they could and gradually we’ve be trying to work towards this goal of eliminating the need to use these internal apis by having exposed public apis and that’s where we get the foreign memory API foreign function API V handle all of those things that then provide a public way of doing these things and this is just sort of like that one step further towards eliminating access to all of the internal API and then we have two final jeps related to 32bit systems JEP 501 and 479 so that’s deprecating and

[45:52] Removing 32bit support for Linux and windows is this also the evolution of systems and we see that yeah everything is now a 64-bit system although I have a lot of raspberry pies behind me which a few of them are still 32bit is this a bit the ID Hardware is moving on so we should do the same with OpenJDK yeah it’s it’s it’s more to do with the fact that you know we don’t use 32-bit systems anymore as you say I mean Windows XP is really kind of like the last time that we saw 32bit operating system they deprecated the windows Port back in JDK 21 I think it was and in JDK 24 they actually have removed the windows 32-bit Port this is this particular Jeff then says right we’re going to deprecate the Linux 32-bit Port but if you think about it you know the idea of if if you had an application that was running on a 32-bit operating system How likely are you want to move it to on JDK 24 or 25 it’s very unlikely you would because most most of the situation there you would actually update your operating system at the same time and move to a 64-bit OS and then be able to use the

[47:09] 64-bit JDK so it’s it’s it’s just tidying up really the OpenJDK source code base yeah and to add to that Simon a lot of new features are very very hard to implement in a good way right in these so what example is the virtual threat project Loom they don’t exist right on the 32bit ports because when you create a virtual thread there they will just create a platform thread instead so that renders the entire feature useless so I think we had all the jeets did I forget something that should be mentioned about one of these well you said at the start of the episode we won’t go through all of them but it appears that we have almost yeah a bit fast maybe but yeah people who want to dive in they can definitely read your blog post Han on Foojay there is also already another one published I think a few weeks ago and there will be a lot more content available in the near future about all these new things it’s a stable release we mentioned it in all the previous podcast Simon every new Java release is a good one you can use it in production it’s as good as it can be

[48:21] It’s completely tested it’s as as stable as we can say that as a long-term support version so why should we switch from 23 to 24 or if we are already on 23 right so this is an important thing to get across the idea of a long-term support release has no bearing on OpenJDK so no OpenJDK versions are classified as long-term support that only applies to the buying distributions that you get from those so Oracle have nominated certain versions as being long-term support releases other binary distribution all of us follow the same pattern as Oracle so 25 will be the next LTS 21 was the previous one but there is absolutely no reason why you wouldn’t want to use a 24 in production the only thing you have to bear in mind is that there will only be updates for six months to the source code and then after that you would then have to think about do I switch to JDK 25 so that’s that’s the only consideration you really have how much Java 23 do you see in production is this something which is used by a lot of companies I would say the majority of the projects that I visit use the LTS

[49:37] Versions exclusively and but in most cases this has something to do with the way they want to structure their work I think they want they don’t want a migration every six months and they want like for compliance reasons they want to be able to report that they are on long-term support releases and in a few cases they’ll have a bit they’ll have like a dependency on an external product that says hey I can only work with Java 21 or 25 but the majority is just we don’t want to migrate every six months or compliancy requires us to be on a long-term support release but in environments where these topics are not as important I’ll always tell them to just use the latest one the one thing I would say is that the only place where I see people who tend to use those the intermediate releases the feature releases I should them of people who have a cicd pipeline that they update on a very frequent basis so if they’re doing very frequent iterations through a cicd pipeline they often will say well if we’re going to update our source code and our product we can deliver on a

[50:48] New JDK at the same time because they’ve got the testing set up so they can run all the tests at the same time so that sort of situation might be where you would see people using that but for most people they’re looking for more stability or where you need a specific new feature that was introduced in one of these intermediate versions that’s also a reason why you can use them okay so 25 will have it in September is it something we should really look forward will it make a big jump from 21 to 25 productivity efficiency energy use whatever I think the one thing I’m going to say about that addressing none of the points you just raised is it has real significance because it’s JDK 25 in 2025 we finally kind of the crossover of the graph I don’t think there are any jeets targeted yet or maybe just a single one stable values I think it’s the only one that has been targeted until now well I’m looking forward to stuff from PR for Hala but of course we can’t be sure if if it is be if it will be part of java 25 that being said probably structure concurrency and the new API for will be there and I look forward to

[52:02] That one and it’s all the intermediate versions which are between 21 and 25 so all these improvements which were there in 22 23 24 they will be there in 25 so you will have a version with a lot of bug fixes a lot of improvements just within the internal system so anyhow It prepares everyone to release to go for the next long-term support version and be ready for many more years on Java yeah and one thing I would like to add is We’ve covered all the jeets this time right but every feature release of java has like thousands of minor performance improvements and security improvements I think when my article is published I’ll have a link to the actual release notes right and there’s always more in a feature version released in just the set of Japs so if you’re if you’re thinking about you know upgrading performance should also be a good Factor there I’ve seen cels of graphs comparing performance of you know recent Java versions and less recent and almost all of the time the recent versions outperform the older ones so that could also be a very good argument

[53:17] To know keep keep up to date yeah I create the release notes of aul zulu every yeah every security release and every major release like in 23 23 there were more than 2,000 JDK fixes which are yeah part of them is jeets but most of them are yeah bug fixes improvements and the whole Community contributing to OpenJDK and applying all these things they have found I always say if you find a buck in your Java application you can be sure that it’s a bug in your codes but from time to time people find something which is really an issue in OpenJDK and either file it as a bug or fix it themsel and that’s what also what I love about this community that you can as as as a volunteer or just a user of java you can contribute to OpenJDK and fix something if you found an issue there thanks a lot both of you looking forward to having more articles of you Han also with the next versions of java I know it’s a lot of work you spend a lot of work on these but it’s really a very nice overview that you give there and I hope you like using Java 24 yeah looking forward to it thanks to my guests for joining this

[54:33] Podcast and thank you for listening please subscribe to the Foojay podcast in your app or on YouTube keep an eye on Foojay for future articles and podcasts about development and everything related to the Java world give me a give me a j give me the friends of OpenJDK