Foojay Podcast #78: Welcome to OpenJDK 25!

Transcript

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

[0:00] Welcome to the first episode of the fifth season of the Foojay podcast celebrating the release of OpenJDK 25.

[0:09] Give me a J of OpenJDK.

[0:14] For the first time, an OpenJDK release is aligned with the year and we can welcome release 25 in 2025. As usual in the release podcast, I have my regular guest Simon Ritter. And today we are joined by Bal Krishna Raul to talk about all the new features in this new OpenJDK version.

[0:35] Welcome. My name is Simon Ritter. I’m the deputy CTO at Azour. been doing Java for a while now since really the beginning.

[0:43] My name is Bal Krishna. I work as an engineering lead at Bank in the Netherlands. I’m using Java for quite some time but I’m really passionate about the new features that are coming up and yeah quite excited to talk about those but also I talk at the conferences about Java features specifically so yeah that’s me thanks for joining both Simon we meet every six months here in the podcast to announce a new Java version I’m very happy about Christian that you join us today to talk about all these this these jets and the changes that are ongoing in Java. So we have Java 25. Is it more important than 24? Is it a big change? How should we look at Java 25? It depends on who you ask. So if you ask the people at OpenJDK, they will say it’s no different to any other version of Java because there there’s no distinction between Java 24, Java 25, Java 21, anything like that. But of course, the reality is that if you look at the distributions of Java, there is a difference because JDK25 is a long-term support release or at least it’s an Oracle long-term support release and everybody who provides a

[1:57] Distribution of that follows the same cadence that Oracle does. So for everybody, it’s a long-term support release. And the importance of that for people who are looking at deploying Java in production is that you have extended maintenance and support. So you can use it for longer than 6 months and get updates to it because if you use 24 for example now that we’ve got 25 coming out that will terminate any updates to JDK 24. So if you were using that in production there’d be no further security patches or bug fixes specifically for JDK 24 whereas 25 they will be for several years to come. Mhm.

[2:35] As far as I know, most companies in production systems rely on these long-term support versions. So, they are stuck on 21 and can now go to 25. But Krishna, can do you know if a lot of people are moving between all those versions every 6 months in production? Me as an engineer or developer who works on Java or who likes Java, for me every is quite exciting. So for me this is also equally big as 20 24 but I can imagine from organizations which are using Java who really want to keep the production systems live as long as possible for them the long-term support is important and therefore yeah this could be a bigger or more important release than Java 24 Cherk 24 and as far as your question about are people moving so from for that reason I see that a lot companies are moving from LTS version from one to the next LTS version. so you would see from 21 to 25 not so much in between releases which are less in between LTS releases. but definitely yeah moving towards newer and newer versions. What I’ve also noticed so generally when I talk about Java in the conferences I also ask

[3:57] To the audience who is using what version in production and nowadays you see more and more people raising hands for newer versions for 21 yeah 17 or 21 which have the new ones even some using nonLTS versions but you see that the trend towards getting the newer and yeah better versions of

[4:18] I think there’s there’s one one other thing that’s worth mentioning about this because it is actually quite significant is the fact that if you look at the Oracle JDK which you know a lot of people have used in the past and still do use Oracle the last license that they introduced was the no fee terms and conditions license which sort of removed a lot of the restrictions that the previous license the Oracle technology network license agreement had which meant you had to buy a Java rescue subscription. So a lot of people thought, okay, great. We’ll use the NFTC license u because that’s essentially free, but it’s not a license that’s used in perpetuity. So in the case of JDK2, it’s been under the Oracle JDK has been under the NFTC and still is, but now that we’ve have the release of JDK 25, the way that the licensing works is that for one more year, you’re getting updates under that NFTC license for JDK21, but after that, which means September 26, it will revert back to the Oracle Technology Network license agreement. If you want to carry on using the Oracle JDK with updates after September 2026,

[5:24] You will need a Java C subscription to use it in production.

[5:27] So there is a license cost which is may be coming if you don’t switch fast enough to a newer version or to complete different runtime. Yeah, another distribution of OpenGDK. we had an interval of 3 years between LTS’s then two years.

[5:45] Will this change? Is the next one 29 in 2 years

[5:49] Or do we know?

[5:50] As far as we know now, yes, Oracle haven’t changed any of the details of that and if you look at the way they describe it, then yes, it is still 2 years between LTS releases.

[6:00] I already saw in June a message and it said exactly we reached JDK 25 final candidate yesterday. So that was in the middle of June, two months ago. So they announced 18 jabs, 2,400 issues resolved, 500 issues closed, thousand enhance enhancements. So that means that there are two three months between that they decide this is the final version and that it’s released. What happens in between? What are fixes to do? Is it paperwork? What happens in between? Simon, I know you’re involved in this process. Can you describe it a bit? Yeah, I mean if if you look at the way that the OpenJDK release cycle works as you say you end up with a release candidate which happens quite early on in the process is you think because it’s like June and we don’t actually get the final release until September the 3 months is so they can do a lot of testing to ensure that the stability of the release when it’s when it’s actually made generally available.

[7:03] Mhm. So that means they’re already looking forward in 3 months to select the release candidate for 26. So but Christina did you already experiment with 26 or are you waiting for?

[7:17] Not yet but I have been experimenting with JDK 25 early access version for quite some time.

[7:23] Yesterday while I was looking at SDK man list Java I could see some early access for 26. So yes, I think after this podcast, the first thing I will do is try and work since I

[7:35] I will point out that as as of today, which is where we’re recording this, which is the end of August, there’s actually only one Jeep that has been submitted in JDK 26,

[7:46] And that is to remove the applet API.

[7:50] Okay.

[7:51] So, not really much to test at the moment.

[7:52] No, it’s a cleanup. But yeah, I think when we recorded the previous podcast that I think you said there won’t be a lot of jabs in 25 or we don’t know yet and now we see that there are how much are there? 18 jabs, 12 are finalized, six are preview. So there can still change a lot for 26.

[8:14] Yes. No. Okay, good. So let’s dive into the details of JDK 25. I think we can find some grouping there in the Jeeps that are part of it. So Jeeps are if we need to clarify that Java enhancement proposals. So they are

[8:31] Actually I’m going to clarify you even further.

[8:33] Yeah.

[8:33] JDK enhancement proposals.

[8:35] Okay.

[8:36] And that is quite specific because if you look at it the reason that we use JEPS is because the Java SE specification that was developed through the JCP only applies to core Java. doesn’t in it doesn’t cover everything to do with the JDK. So JDK enhancement proposals cover things which are not part of the Java SE specification as well.

[8:55] Okay. So I need to probably review a few blog posts if I didn’t write this on the wrong way. So JDK enhancement proposals. So that is not a bug fix or a small code improvement. That’s really something new. and I have grouped them because they’re also related to projects. So a project is a bigger thing within OpenJDK to do something and let’s start if that’s okay with you for with project leen which wants to improve the startup time time to peak performance and footprint of Java programs. So we have two jabs there 514 515. Can you explain what’s really in there? As you said, Frank is all about improving the startup times for JVM apps and there are two jeeps there Jeep 514 and 515 and they both focus on AOT computation. So ahead of time which is one of the features that is really important for improving the startup time. So what actually happens in the AOT process is that when you run your production your application in a production like environment you create a cache which is useful when you actually run it and then you can use that cache to improve the startup time.

[10:12] Now these two one of them is for AOT command line ergonomics. So basically creation of the AOT cache is a two-step process. there is step one which is basically recording of the cache and then step two is to actually creating the cache and these two steps happen with two different commands normally before this job but with this job you can do it in one step. So basically pass one JVM argument and then that takes care of doing both these steps. So creating the cache basically recording the configuration as well as creating the cache and then the second jeep which is Jeep 515 if I’m not wrong that’s about improving the AOT cache by adding some method profiling information. So recording information about methods yeah what all data they need and then that is basically part of the cache and then there also improves the startup times if I understand correctly. So you need to run your application with some ahead of time arguments the first time it takes longer and then you can reuse that in a later phase if you restart your application so

[11:24] That it starts faster. Correct?

[11:26] Yes. Yes. how does this compare? So there are more ways you can speed up this startup of application. So you have grow VM if you completely compile it to a native image. Eclipse has open J9, you have filidon, you have crack, you have ready now inul zing. What is the difference? Do are they trying to have OpenJDK providing a solution that can replace all these alternative approaches? It’s interesting because I’ve I’ve done a presentation on this at a number of conferences which is essentially what we’re looking at is solving the JVM warm-up problem because if you look at the way that Java works you compile into bite codes rather than instructions for a particular platform. That’s the way it’s always done and the reason behind that is to have the write once run anywhere concept that was delivered right at the very beginning from Sun.

[12:21] But the issue that we have with that is that in order to deliver better performance, if you just run in interpretive mode, you get very poor performance compared to natively compiled code. So the idea of adaptive compilation and using just in time compilation was introduced back in JDK 1.2 1.3. And so as the application runs, we identify which methods are called most frequently. We then compile those on the fly inside the JVM first with a quick compiler which doesn’t do any optimization and then we profile the method in order to gather information about how it’s being used and then we recompile it with an optimizing compiler. That takes time to identify all of those methods and do the compilation to get to the optimum level of performance. So that’s the warm-up time. And what we want to do is try and find different ways of solving that problem. Now, as you rightly point out, there’s a whole bunch of different things that people have done in the past to try and eliminate that problem. One of which is Gravm, which is taking the sort of very extreme solution, which is to say, well, rather than using bite

[13:23] Codes, let’s compile everything in Java into native instructions straight away, generate a native image, and then you eliminate the whole problem of warm-up because you’re running straight away from native code. But of course, the downside of that is that you’re not profiling the application as it runs. So the code that you compile isn’t necessarily optimized for a particular run of the application. So you will typically get lower performance on a natively compiled application than you will with a JIT compiled application. Things like crack are an alternative approach where we’ve said well let’s freeze an application at a given point and then restart it later. But again that has issues in terms of the way that it works from point of view of you know you have to basically persist the entire heap which means if you’ve got a big heap there’s a very large thing you have to persist and there are various other sort of considerations in terms of how you stop and restart an application ready now as you point out is a product that we include in zing that’s very similar to what project lighten is doing

[14:21] Because ready now was all about saying okay let’s let the application warm up and then record a profile of that running application which contains information about what methods have been compiled, what profiling information was collected and so on. And then when you restart the application, rather than going through the same process of identifying methods and compiling them, we immediately feed that information into the JVM and allow it to do that compilation straight away before you start your application. So the project Leiden is taking the same approach. It’s saying okay let’s record profile information of a running application which is using JIT compilation and then feed that back in again at the beginning so that we can get better performance and faster warm-up and as was rightly pointed out one of the jets is about reducing it from a two-stage process which I never understood why they did it in two stages to a one-stage process because you know you can do it all in one stage and then the method profiling which is again taking that profiling information about how methods

[15:21] Are used so you could feed it back in again and make it faster to get to your optimum level of performance. I

[15:26] I think also one of the other differences is so you have this project lighten which takes some time to get into open GDK. So now in 20 now in this version we have these these these new jets is that also difference with like crack ready now that is also implemented in older versions of the JDK. So people can already use those if they are stuck to an older code base.

[15:53] Yes. I mean crack was introduced we provided it for JDK 17 and we have JDK 21 and we obviously have JDK25 ready now I think we’ve been using or good since JDK 8 so that’s been available for older versions as you say Leen and the Jets for that is taking some time to be introduced

[16:12] And probably lane will take some more OpenJDK releases before it’s fully implemented. So yeah, it’s improving but it’s not a final solution yet. Then we have another OpenJDK project which is Valhalla. again the goal of this project is to enhance Java’s type system and memory model so that developers can write high performance memory efficient code without sacrifying Java’s object-oriented abstractions. I have to admit I have to write these down before we started recording so that I have a clear description. This project fala brings three chaps. there’s one which is finalized. So that means that everyone can use it without extra arguments. And there are two which are incubator and preview. That means you can only use them if you en enable this with a command line option. So what is evolving in OpenJDK thanks to Valhalla? Compact object headers, right?

[17:07] That’s one of the J that is finalized in this version of JDK. and as the name suggests it is basically compacting the object errors into less space. So when you initialize objects it takes less memory becomes more efficient. and this one is especially important when your applications are running in containers or serverless infrastructure because then you can have more instances run in the same memory space. So that’s one Jeep. The other one you mentioned is vector API which is in its incubator. So vector API it takes advantage of SIMD single instruction multiple data and that is a concept where in certain CPU architectures it is possible to have multiple operations done in one CPU cycle when you’re doing the same operation on multiple pairs of data. and this is quite a natural choice when you’re dealing with vectors because vectors are series of data and when you apply an operation on two vectors you basically are doing the same operation on the on multiple pairs of the same let’s say multiple pairs of same data and then you apply that

[18:28] Operation on them. So you could do that in one CPU cycle and that is what is taken advantage in vector API. and vectors are nowadays quite popular because of vector databases algorithms and models which rely on vector representations of data. and therefore utilizing that for processing these vectors in a you know faster manner

[18:54] Is something that is done as part of vector API. But I see that it’s the 10th incubator version. So that means that it’s already 10 releases. Yes. That it’s not finalized. And I can remember Simon that you said the previous time. I hope and maybe it will be in 25. So why is it taking so long time if it’s so important for AI calculations and all the big things which are now happening?

[19:24] Is it not finished? Is it not ready? it it’s if because it is related to Valhalla. If you look at the Jeb, this is what I didn’t actually notice this when I was reviewing it before, which is why I mentioned this in the previous podcast, but if you look at the Jeep, it actually says that because it’s part of Valhalla, they don’t want to make it final until they introduce some of the bigger parts of Valhalla because there might be some changes that are necessary based on how they decide to implement those parts of Valhalla that are not in the JDK yet. So that’s the reason they haven’t made it final. So yes, we’ve been through 10 iterations. It is the record holder for the most incubator iterations and it will continue to be an incubator until other parts of Valhalla come in.

[20:06] So if I really need it, can I use it? May I use it in production?

[20:13] You absolutely can. You just have to remember to set the flags to say use experimental features. Yeah, but it’s not that it’s bad codes or unfinished code or untested.

[20:27] Exactly. And that’s one of the things that actually sometimes people don’t necessarily realize about the way that preview features and incubated modules have been implemented. This is not about introducing beta features where it’s in development is still being you know developed and tested. This is about delivering a fully formed completely ready feature which can be used in production. It’s just that what they’re saying is that there is the potential that they might need to make some changes to it in the future based on feedback based on the way that people are using it. So that’s the thing but it is a fully formed feature that you can use in production.

[21:04] Okay. And another preview feature is stable values Jeb 502. That’s the idea of immutable values in Java because this is one of those things that’s always been a little bit of a struggle shall we say in Java. You have the concept of final and that you can make a variable final and that theoretically says that it has only one value. But the reality is that doesn’t actually mean that it’s truly final. And the reason I say that is because if you create a final field in your class or if you create final variable in your method for example, it has to be set once and once only that’s fine. Okay, so you can’t change it but you can change it if you use reflection. So it is still possible to change a final variable if you really want to. So it’s not truly immutable. there are some other drawbacks with final in terms of the fact that you have to assign a value to it when you instantiate it. so what the idea behind stable values is to give you more flexibility over how you can make data immutable and from the point of view of the JVM it is truly immutable in that you can’t change its values in

[22:17] Any way shape or form. So the ability to share data between different so this is like I say it’s related to Valhalla which is value types where you have truly you know and if you’ve got a three as a value that’s always going to be three. So if you’ve got several different immutable values that are three you don’t have to create three different instances of it. You can have one instance and all of them point at that. So it’s it’s kind of linked to that immutability thing.

[22:46] It also adds this deferred immutability concept. So basically values as as Simon mentioned for final you have to initialize them in constructors or in static initializers. but with stable values they get initialized when they are first time used. So they’re the objects are not created until you actually use them which also helps in yeah first of all adding the immutability part but also not creating those objects so it doesn’t waste CPU or memory.

[23:14] Yeah that that’s a very important distinction to make. So yeah good point. Next project is project loom which focuses on improving Java’s concurrency model. Is that where we got virtual threads from?

[23:25] Yes.

[23:25] Okay. Good. and it has also some extra enhancements. Now the first one is Jeep 506 which is scoped values. as you mentioned Frank it’s about project loom right and the goal with loom is to provide an API which is you know supporting this high throughput lightweight concurrency but also something that is easy to use and in project loom this is achieved with these three main features virtual threads structured concurrency and scoped values virtual threads has been final since Java 21 I believe and it provides this high scalability right these are lightweight user threads and because they’re lightweight you can create them thousands or millions u millions of them which was not possible with the traditional platform threads.

[24:12] There’s another feature which is supported as part of project loom which is structured concurrency and virtual threads actually make structured concurrency possible. it is because with platform threads we had the limitation that we could not create large number of them because they are resource intensive. so what you did was you created few of these platform threads and you use them very efficiently. essentially you view a platform thread as a process and then you submit multiple tasks to it. but because the limitation of not being able to create large number of these threads has been removed with the introduction of virtual threads. You can create multiple virtual threads. You can in fact create one virtual thread for every task that you’re doing and then you can arrange these tasks in a more logical way that your domain demands right and therefore you can write concurrent programs which are also readable right and that is the goal with structured concurrency. So the advantage with concurrency is that we can arrange these tasks in structures or patterns that represents your domain

[25:15] Requirements in the most logical way in this project. So this Jeb exposes this API called structure task scope where you create an a where you create a scope and then you fork tasks from it. and essentially this whole scope is seen as a single unit of work. So you basically fork and join these tasks in a single code block and because this is a single unit of work you either complete it successfully or you fail with an error. Now the structured concurrency has been there previewed multiple times. that has been there for multiple versions of JDK. the change that has been done since JDK 24 is addition of this concept of joiner. so when you create a scope now you can also pass a joiner and then the joiner defines how do you want to join these tasks. So do you want all of them to be successful or any one of them to be successful or some other configuration of these tasks that you want and you can also create your own joiner. So this joiner is the new thing which has been introduced with JDK25 and this Jeep still stays in its preview. So it is not

[26:26] Finalized yet. I think the JDK team is waiting for more feedback before they can finalize this API but one that is finalized is the scoped values feature right and scoped values is a better alternative for thread locals. Now essentially a thread local as its name suggests is an object which is local to a thread right when you define a variable with thread local type then every thread get its own copy of that object and then each thread can mutate that object and those mutations are visible within that thread. but there are certain problems with thread locals. they allow for unconstrained mutability. So there are a couple of methods get and set and you can do get and set on an object within that thread. and it is not constrained right and because this mutability is not constrained it creates more problems. you really want to strive for immutability and therefore that is not achieved with thread locals. Also there is unbounded lifetime. So there is a method called remove on thread local and you have to ensure that you call that method when you are not using the thread local

[27:37] Object anymore. but developers often tend to forget to call this method and there you can also then have thread local objects which stay with the thread more than you need them. so you really want to avoid that unbounded lifetime and you want to make sure that it is only possible within a certain scope. and thirdly, u there are inheritable thread locals which are passed from main thread to the child threads. and when they’re passed, they’re actually creating a new object for each thread. Now if you use these inheritable thread locals with virtual threads because virtual threads allow for thousands or millions of threads you would end up with thousands or millions of these thread local objects and you don’t want that because it would take a lot of memory and it would be cumbersome for your application to handle. Now all these problems are solved with scope values. and I’m really happy that scope values is now a final API. So we don’t have to use the flags to use scope values. yeah so with scoped values the there is an only let’s say a single object created and that object is

[28:49] Used within the scope. So the mutability problem is not there also it is defined the bound what do you say the lifetime is bound to the scope of the scope value that you create and therefore you don’t have unbounded lifetime. also because there’s only one object which is being read by all the other threads you don’t have the problem of using lot of memory like you had with thread locals so that is also an advantage of using scope values

[29:22] I really couldn’t add any more to that in terms of a description of the new features because that is very comprehensive description of what they include I think the only thing I’d add to that is this is a demonstration of how Java has evolved over time as we know Java 30 years old this year. And it’s interesting because if you look at the history of Java, one of the things that has continually been sort of addressed and we’ve had more and more things added is how to write multi-threaded and especially cooperative multi-threaded applications. if you go right back to the very beginning of Java, you literally had the thread class and the runnable interface. And if you wanted to write threads that cooperated amongst each other, you had four primitives that you could use. you got interrupt, sleep, wait and notify and trying to write application code that was rel reliable using those was almost impossible. So we’ve seen you know the introduction of the concurrency utilities back in what was it JDK 5 with semaphors and mutxes and all those sort of higher level functions. Then we

[30:22] Had the introduction of the fork join framework in JDK 7. We had parallel streams in JDK8. we’ve had as obviously virtual threads in JDK21 and there’s been continual sort of improvements in the way that we can write cooperative multi-threading threaded applications and this is a good example of that to make life easier for developers

[30:44] And all based on feedback because yeah these virtual threads they were also in preview for a long time. So it’s really something which is based on what people really need and feedback they get from the community as yeah this is a good example but we want to use it in another way and how all this fits together. I find it very yeah fascinating people say Java is not evolving fast enough but it’s because decisions are really structured and they are thinking ahead. Maybe you already explained it with the vector API. It’s not finished because it’s needed for future things where they are working on and they want to have something really really good and stable.

[31:30] But that’s one of the things that I find most impressive about the way that Java develops. If you look at the whole sort of process that’s involved in the jets and the way that the architects so the people like Brian Girtz, Mark Reinhardt and so on, the way that they very very carefully evaluate new features and look at you know what is the impact of that feature going to be on the language and if you read the OpenJDK mailing lists especially the Amber mailing list Brian Girtz is I mean I have so much admiration for him as a developer because he will respond to people’s queries on that mailing list. People will say, “Why don’t you do this or why don’t you do that or why doesn’t it work this way?” And he will write really long, very thoughtout reasonings as to why the decision was made to do something a particular way and not a different way. and so it is it’s very encouraging the way that Java develops using that sort of approach that we don’t get a Python 2 Python 3 moment where suddenly everything breaks because they’ve changed the way things work.

[32:41] Yet we are evolving the language and adding these new features but in a very nicely controlled way. If I may add one admiration of my own is about this possibility of using incubator features or preview features because that gives us a lot of power to the developers like us you know we can try these things and give that feedback but trying these things firsthand is an exciting experience and I am really glad that we have that in Java and we are able to do that

[33:09] And that was a result purely of the fact that we switched to the six-month release cadence. We couldn’t have done that before because if you introduced a preview feature and you had to wait 2 years or 3 years before we could update that preview feature, it just wasn’t going to work. But because we have a 6-month guaranteed release cadence, you can do preview features and say, “Okay, it’s preview feature this time. In 6 months time, we might make it preview feature again, but in another 6 months time, we might then make it final.” And that works really well.

[33:34] You mentioned the Project Amber mailing list, which is really great because that’s the next bullet on my list. So, Project Amber wants to make Java more expressive and consist by introducing small productive focused language features. It’s not about radical changes like the other projects we mentioned before, but about removing boiler plate and modernizing the language while keeping Java’s readab readability and safety. And we should add backwards compatibility because you can still run your old Java applications on your runtimes. I think I found four Japs in this one. module import declarations 5 1. 512 is compact source files and instance main methods. 513 is flexible constructor bodies. And we have a third preview of primitive types in patterns instance of who wants to take which one.

[34:28] Primitive types is a good one because I like that it makes life easier because one of the problems that we’ve again the way that Java was developed right at the very beginning was it wasn’t a truly object-oriented language. So we don’t treat everything in Java as an object and we have primitive types. Reason behind that was in order to deliver better performance because if you do treat everything as an object back in the ’90s it just wasn’t going to perform the way that it needed to. So we had primitive types. So you end up with wrapper objects and you know it gets there’s a bit of an impedance mismatch there. So in allowing people to put primitives values or primitive types I should say into instance of and switch and so on I think is a very useful feature. However, it also introduces a number of kind of edge cases because if you look at the jet and you look at the description of how things work with different primitives, the whole idea of automatic promotion where if it will fit into an int, it becomes an int. So even if it’s you know 210 as a value, that will

[35:36] Fit into a bite, but you autopromote that into an int. that has some interesting implications when you look at how the pattern matching works in terms of primitive values. So there there’s certainly some things that it’s well worth reading through the jet on that carefully to understand exactly how this works with primitive values. so that that’s one thing. The other thing I’m I’m going to I’m going to talk about is the compact source files. Yeah, which is my least favorite feature. And I say this every time because I don’t I’m I’m in my opinion I don’t see the point of it. I get the idea behind it which is to make it easier to write your very first Java application. But once you go beyond writing hello world, you need to understand all the details of how public static void main works and how a class is declared and so on. So it’s a nice idea, but I don’t really see a lot of value in it personally.

[36:31] Yeah. Okay. It’s a discussion we have each podcast since these chaps exist. I like to write tutorials about Java and then but I have to admit I most of the times I use Chibbang to create a tutorial where you can add dependencies which you can still not do in just a Java file and start it. So yeah, it’s a bit it will be a discussion forever Simon but it’s now finalized apparently. So because we had two preview features.

[37:05] So the good news is that we won’t need to talk about this next time.

[37:09] Yes. We will need to find another discussion topic.

[37:14] But Chris there are two more of these jeeps in amber. You want to take these?

[37:18] Yeah. Yeah. Maybe I just want to make one more comment because I think the compact source files or instance main method may not be the only Jeep in this topic. There will be subsequent jeeps I guess and you might have to talk about those heck. No problem.

[37:33] But yeah, there are two more Jeeps which is one of them is module import declarations which basically means that now you can import a module and then it would import all public types from that module which were all from the packages which were exported from that module. So it avoids lot of clutter in your import statements. I think it’s an nice little advantage. it also facilitates the use of modular libraries, libraries that make use of modules in simple programs. So it’s I think u a nice actually amber project amber is something that I really like because it enables us to write readable programs and readability is something that I really care about.

[38:20] So when I see programs which I can bright the way I think about them I really get excited about those and project amber is doing that and these are nice utilities which fit pretty well with each other to write these readable programs. And then we had one more which is about the constructors. so basically in the past every constructor had to have their first statement as a call to another constructor or call to a super constructor which is not the case anymore with this job. basically you can nicely validate any arguments that are getting passed to the constructor before you can call any other constructor or super constructor. So it frees up from certain limitations that we had before. Also it is a final final feature. So yeah pretty good to use.

[39:12] So yeah it’s all about this amber thing is all about readability as you say Marit Fella at Jet Brains even has a talk that you read more codes than you write code for most developers. So

[39:28] There are some nice blog posts about the reduction in code that you need for similar functions across all the releases of Java. are there other big changes that we can expect in Project Amber in the next releases that you know of?

[39:42] I know that they’re looking at more places where they can apply pattern matching. That’s that’s one area that is still being investigated.

[39:50] Mhm.

[39:50] Yeah. I guess the withers might come somewhere or in some shape shape or form.

[39:56] That’s true. Yes. Yeah, that that’s another but that that’s one of those ones that is quite contentious and trying to get the format of that right is going to be interesting. That’ll definitely get through a few iterations of being a preview feature.

[40:08] Yeah, it’s basically a feature where when you have an object already created, you want to create a copy of it with a slight modification. now you have to create an entire new object and then set everything. but could we do that in a more ergonomic way? You know, something which is simple and concise, also reads nicely. and because of these constraints, again, there’s a lot of discussion about how you can get there. we will see some version of it in the future as part of project. but to be honest, I really like the switch expressions. I’ve been a fan of it since they were introduced and I think they are more powerful than you can imagine. There’s a lot of utility to it in u writing expressive code and writing complete code. So you make less errors. and it has been evolving over these different versions of JDK. and I really like that you know switch expressions quite powerful

[41:09] And use them often to write readable codes.

[41:13] Yes. So that that’s a good example of where again thinking about the history of Java. when Java was first released, it was based very heavily on the syntax of the C programming language. So the C programming language had the switch statement and it had various ways that it worked. One of which was the fall through. So if you don’t put a break statement in with a block of cases it will fall through to the next set of cases. And that’s by design for the C programming language and that was adopted into Java. probably with hindsight it would have been better not to do it that way but it was to make the transition from C programmers to Java programmers easier that they wanted it to be familiar and we’ve seen that as you quite rightly say with switch expressions now we’ve eliminated a lot of that potential for error by having an expression which returns a value so the compiler can check that for each set of cases you either return a value or you throw an exception so it’s it’s a very powerful feature like you say Maybe if I can add one more thing about project amber because they really like

[42:17] This project as well. one of the things that the architects have achieved by combining these features together is data programming. so data programming basically emphasize on writing well first of all encouraging immutability writing immutable objects which encapsulate data and then you have the behavior that operates on that data separate from the definition of the data. and a lot of features from project amber allow us to do that. So basically you can model your data using records and things like sealed seal types and you can model your behavior by using all these pattern matching features. and it is again a powerful philosophy to incorporate in our programs especially in the fields where we operate and you have microservices which just deal with data you know getting some data changing or transforming it to something else and passing over into the next thing in your pipeline there you can really use the state programming quite quite well and that is something which is possible as part of project amber

[43:25] You already invited the people Simon to read the chaps because those are really nice descriptions about how we want to do something and why and what was different before, what will be different afterwards. the same goes for these projects. I think they all have their own page or website within the OpenJDK project. Can anyone join a mailing list for instance like Project Amber? Is anyone allowed to join a mailing list where these enhancements are discussed?

[43:56] Oh, absolutely. Yes. so it’s it’s quite easy to do. You can go to the mailing list for the project and you can sign up to it and like I say, I mean lots of people post questions and suggestions on these mailing lists. and that that’s quite possible to do. And like I say, people like Brian are very responsive.

[44:13] An invitation for everyone to check the project pages if they’re interested really in why this is designed like it is. I have another Jeep that we should talk about and it’s in the garbage collectors. Jeep 5 to1 makes the generational mode of Shenandua final. It has been there in JDK 24 but it was only available with an experimental flag. Correct.

[44:38] Yes, I think that is just making it final so that you don’t need to use an experimental flag for it.

[44:43] Yeah. Okay. So, not a big change. It’s just simplifying again to use it. So what is the difference between generational garbage collector? I know that this is a question which can take hours.

[44:57] Generational garbage collectors. Yes. there is a thing called the weak generational hypothesis and that basically says that most of the objects or in fact almost all of the objects that you create are only used for a very short space of time. and the sort of the kind of general data is that like 98% of the objects you allocate will become garbage before you allocate another megabyte of data or before you’ve executed a you know a few million instructions which doesn’t take very long. So the idea is that most of the objects you create are very very shortlived. So generational heap space is all about saying well if we divide the heap space into a young generation and an old generation. We can apply collection differently to those generations so that we can deal more efficiently with all these shortlived objects and then treat the ones that do live for longer differently and move them into the older generation. Now, that’s something that’s been around really almost since the beginning of garbage collection as a as an algorithm.

[45:57] And most algorithms use a generational garbage collector. Now, when Shannondoa came out, they decided at the very beginning that they wouldn’t use a generational garbage collector. They would stick with a single heap space and they would do everything in that one space. And they did a lot of work on that and that all worked very well. But they discovered that the weak generational hypothesis actually does apply. And they found that in terms of performance, they could deliver either very good performance with a large set of data that didn’t change much or a small set of data that did change a lot, but they couldn’t do both. So they essentially went back and said, “Okay, we’re going to change Shannondoa to become a generational garbage collector.” And that took quite a lot of effort, quite a lot of rewriting of code, but they’ve now done that. They’ve introduced it as a preview feature and now it’s been made into a full feature because it’s finalized.

[46:51] The same thing actually applied with ZGC. They started out with a single generation and then they decided that actually yes, the weak generational hypothesis does apply and it’s better if they used a generational heap space.

[47:02] So with this it is still possible to use the single generation mode, right? So basically this is an optional mode that is available but as you mentioned I think it is definitely advantages over using the single generation.

[47:13] That’s right. Yes.

[47:15] Garbage collectors I didn’t even know that they existed when I was just doing Java development because that’s a bit the idea of Java. You don’t need to care about this thing. It’s handled for you. Then I discovered that there are a long list of garbage collectors. Then even Azul has their own one. there’s a fascinating talk by Garrett Grunwald, the trash talk, where he uses Java VIX applications to visualize how memory blocks move. I really like it. I will add a link to the show notes. But yeah, this is it’s a fascinating topic. It’s very technical

[47:51] Garbage collector. I have two books

[47:54] About garbage collection and they’re both like three or 4 hundred pages long. and then you have to imagine that most people don’t realize don’t need to care to you don’t need to know it but it can help you to select the right garbage collector for your kind of use that’s a bit the basic story there another hot topic security there are two jeeps I have found one is a final one is a preview so we have j 510 key deriviation function API can you explain Like with security where we have these two chips as you mentioned Frank first is about key derivation function. These functions are actually algorithms that are used to create cryptographic keys with this Jeb. Now we have couple more algorithms supported. do I know the names? I mean I’m not really aware of the interns of these things but I think one is called

[48:52] I just refer people to the jeep.

[48:55] Yes, exactly. Maybe refer to the jet and then you know which exact algorithms are supported. but I think the main idea here is to support the postquantum cryptography. basically when quantum computers become strong enough that they can break the cryptographic infrastructure that we have. So we need stronger algorithms like the ones that are being supported in this j and this j was already present. It is now just made final. so yeah it’s good to see that we have work going on to have these quantum resistant algorithms being supported in Java as well.

[49:27] Mhm. so that’s one security feature and then the other is about the PM encodings of keys and certificates. so PEM is basically a privacy enhanced mail. It is a text format where you can u export your cryptographic objects like keys and certificates onto. so with this J now we have a preview API which can encode and decode these keys and certificates into PM format. PM is especially important because it is widely supported in like OpenSL or OpenSH. also with this step you get a simple API to do that and basically you can now write Java apps which deal with PM. So yeah it’s it’s a nice addition to have Java.

[50:14] Obviously the thing with security is we’re always facing a battle between those people who want to try and break encryption and the different algorithms so on and people coming up with new algorithms which are harder to break. So that’s why we see a continual sort of flow of these types of jets where they’re including new algorithms and new APIs and so on for these different features. And I would say I just love the idea of quantum resistant APIs. It’s just sounds cool, doesn’t it?

[50:41] Yeah, the name is cool. But isn’t that nice that I don’t know if this already an existing threat this quantum breaking algorithms but isn’t it nice that the Java community OpenJDK community is already working on implementations to be ahead of or be prepared for such security flaws.

[51:05] Yeah, I think that see the quantum resistant thing is already a known issue that security developers and security experts are working on. So the idea is that in terms of Java, we’re trying to make sure that we keep up with those things. so like the continual battle.

[51:20] Mhm.

[51:21] The thing is that if you wait until it becomes a problem, then you’re too late. So that’s why it’s always good to

[51:28] Then we have a few jeeps about Java flight recorder. So that’s a tool to check what’s going on in your application so that you can for instance see which thread gets blocked and stuff like that. So you can look into the internals of your running applications or if you have some kind of recording. so there are two finalized one is experimental. Again the question can you explain what is changing within OPJDK for JFR. There are few JFR related JS in this release. as you mentioned Frank one is experimental and I think couple of them are final. so JFR yeah JFR is JDK flight recorder. So basically for any Java or JVM application you can have the different events monitored and recorded. So you can use them to improve your applications. Now few things that are added in this release one is JFR CPU time profiling which is experimental feature. So with this now you get better CPU time profiling.

[52:35] So basically you can check how much time how much CPU time your method took. so you can make some optimizations around that. then you have JFR cooperative sampling. So with this J you get a better thread stack information within your JFR. and basically instead of sampling it at arbitaryary moments in the lifetime of your application these are now sampled at some safe point. So you have let’s say safe thread stack sampling with this JFR and the third one is JFR method profiling. So you get better method profile information in the JFR. So example the execution time. So you know more precisely now how much time a method took and their stack traces. So those are included in JFR. These the last two are final features. So you can use them already. flight recorder is a very powerful set of features for instrumenting JVMs and understanding what’s actually going on because it uses the information that’s already available in the JVM a lot of the time so that it’s it’s simply exposing that externally so that you can use mission

[53:52] Control or something like that to see what’s going on in a running application or use a postmortem analysis if your application crashes. and as you rightly point out the you know there’s some improvements in that. I guess one thing I did thought was quite interesting was the CPU time profiling jet which I think is the one that’s still in preview. that only applies to Linux which I thought was interesting because you know it’s not a crossplatform jet.

[54:17] I mean the one thing I can add about JFR is that it’s it’s a it’s a very interesting and powerful monitoring tool. and one of the goals that they have at JFR team is the overhead of this monitoring shouldn’t be more than 1% of the directory. So which is actually a pretty good goal. So you can be assured that it like monitoring doesn’t add anything extra load on your application and you get all the profile information at pretty minimal price. So it’s a

[54:48] Exactly because the problem with instrumentation like this is that Heisenberg’s uncertainty principle actually applies to instrumentation of computer systems. You know the act of observing something changes what you’re observing. So you can distort the way that your application behaves by adding more instrumentation and of course it takes longer to collect all that information. And that’s where method profiling becomes an issue because if you start method profiling the overhead of doing that is quite severe. But what they’re doing here is saying well we’ll only profile certain methods to minimize the impact of that. So it’s it’s done in a controlled way.

[55:24] These different projects they also have dependency on each other. They interact with each other. So recently we also had some Jeeps. I’m not exactly sure which version of JDK was but which was support which was supporting new events specific to virtual threads. So basically project loom had an impact on JFR and then JFR supported these new events which could make profiling your virtual threads is easier. So we can also see that non different projects collaborating and having impact on each other.

[55:54] How do you compare a JFR recording with a garbage collector lock? Those are two different things you can enable within your runtime so that you create or profile or garbage collector log or both. What kind of information will you get from those two?

[56:13] So, so those are independent. So, you can create one or both, one or the other or both. garbage collection log is just information about how the garbage collector is operating. So, when the garbage collector kicks in, how long each garbage collection cycle takes and information about how much garbage for example is recovered. Java flight recorder is much more generic in terms of it applies to different aspects of what the JVM is doing. So like method profiling is understanding how long you’re spending in a method. looking at how much memory is being used for certain things, how many objects are being created of a specific type which you won’t get from the garbage collection log. So there’s a lot of different information that the flight recorder generates.

[56:55] So if you are facing a block threat for instance, you have to look into the GR recording. That’s where you have to be.

[57:02] Absolutely.

[57:03] Okay, good. we went through a whole list of Jeeps. I only have one left and it’s a cleanup. I think it’s 503. Remove the 32bit x86 port. is it just a cleanup? Does something change in codes? Does it make Java incompatible with certain platforms?

[57:25] It is a cleanup. I mean one of the problems that you face is that when you introduce features like virtual threads trying to implement that in 32 bits and also the comp compact object headers things like that become very difficult when you look at these much older architectures. So, the idea that somebody would be using a 32-bit operating system and want to move to JDK25 is very unlikely except in the situation where you’re using perhaps an embedded system. But for any general purpose computing where you’re running on a server or a desktop, the likelihood that you want to run Windows XP on your desktop and run JDK25 or later is pretty minimal. It’s, you know, there isn’t any point. So the cleanup is to remove the 30 bit 32-bit port for Windows. The 32-bit port for Linux has already been removed. So it’s it is just tidy up in that respect.

[58:22] So that means that OpenJDK from now on is 64-bit only.

[58:26] Yes. Yes. So that’s the way forward. I have to dump a few Raspberry Pies on my side. But and again only the older ones. It’s as you say, platforms evolve, systems evolve. I don’t think production servers are in use with 32-bit systems in the

[58:46] Technically you don’t need to dump them because you can still use JDK8. You can still use JDK11. You can even use JDK 17 if you really want to.

[58:54] Mhm.

[58:55] We briefly mentioned one Jeep in 26 is already selected. if you don’t look at Jeeps, what are the big things that we can expect in future versions of Java?

[59:07] I’m looking forward to structured concurrency between finals. So that’s something that could happen 26 maybe. See

[59:13] And Simon you are in a lot of groups working behind the scenes so you have inside information you cannot share. is there something you do can’t share about it? I can share my personal perspective. I don’t think I really have access to any information on the I mean I’m part of the Java SE expert group under the JCP but we don’t really or we don’t suggest new features anymore. This is more about just finalizing the standard. Valhalla is the big one that we’re we’re waiting for features to come from that. and then obviously there’ll be a few tidying up things with project loom. I think project Panama we’ve now delivered everything in terms of the foreign function forum memory interface. So I think that’s all all done. project amber will continue with things and then object project Leiden will deliver more things as well. Bakrisha, will you start moving your servers to 25?

[1:00:13] Oh, will I? Yeah, I am already using JDK 25 in all my personal projects. So, since early access becomes available, I would move into that. Yeah, I’m really looking forward to 25 and future versions. But maybe one question, Simon, if you know from your inside sources, will we have value objects in 26, 27?

[1:00:32] I actually don’t think so. I think that the development of those is still a little way off unfortunately. So I’m I’m not sure 26, maybe 27.

[1:00:43] Okay, we’ll keep waiting.

[1:00:44] Yeah, maybe aim aim to the for the next long-term support version.

[1:00:49] That’s when we get to the 99th iteration of the vector API.

[1:00:55] One day you will say it’s finalized.

[1:00:59] Okay. thank you both for your time. Thank you for joining this recording. Thank you also to the listeners of this podcast. if you like it, if you want to be aware of all the changes in Java, please follow us on YouTube or your favorite podcast app. See you next time and thanks for joining.

[1:01:17] Thank you very much.

[1:01:18] Give me a OpenJDK.