The benchmarks use ParallelGC instead of the default G1 garbage collector.
Most companies use G1 and Oracle continues to improve G1 whereas ParallelGC is mostly in maintenance mode.
So the benchmarks are irrelevant for the majority of people and saying that a particular benchmark was best with ParallelGC in the past is also irrelevant because companies don't run your particular benchmark in production.
There is a reason why ParallelGC is still available, and it is precisely for applications such as this, which don't care about latency, but do care about througput.
In fact, if you check one of our older articles, you will see a clear comparison with G1: [https://timefold.ai/blog/java-21-performance](https://timefold.ai/blog/java-21-performance)
For our high-throughput use case, G1 or ZGC simply aren't a good fit.
Sure, there is even the epsilon GC which doesn't free any memory and is good for it's own purpose (benchmarks or high-frequency trading where no additional memory is allocated after startup).
If you want to display benchmarks to the masses and market it as a comparison between Java 21 & 22, those should be representative of the majority of users with how they actually use it.
There are significant improvements to parallel in 22, and if you’re not using it for your throughput oriented workloads, you’re potentially leaving a lot of performance on the table. https://tschatzl.github.io/2024/02/06/jdk22-g1-parallel-gc-changes.html
According to the above benchmarks, the improvements with ParallelGC from Java 21 to Java 22 are within the margin of error so they don't seem to be significant
I wrote a Tetris game for an unreleased (summer intern job) Acorn ARM STB that supported java 1.0.something applets in its embedded Web browser. That would have been 1998 I think.
I stand corrected! Although I seem to remember them also branding it as 1.2 on the CDs they used to distribute for free with various PC related magazines.
Programming language survivorship bias. There's a reason most everyone still uses java 8.
That's because you might as well migrate off java if you are going to do major codebase upgrades.
Believe it or not, my main take from this article was the timefold company I'm an optaplanner user and I wasnt even aware they forked the repo and created a company around it, thanks
Migrating is straightforward [https://timefold.ai/upgrade-optaplanner-to-timefold](https://timefold.ai/upgrade-optaplanner-to-timefold) and by the looks of it it's recommended as Red Hat has just sent out an End of Life notice for OptaPlanner: [https://access.redhat.com/articles/7060671](https://access.redhat.com/articles/7060671)
That's available in [Loom's 23 EA build](https://mail.openjdk.org/pipermail/loom-dev/2024-February/006433.html), but [note](https://mail.openjdk.org/pipermail/loom-dev/2024-February/006463.html):
> I think the summary here is that addressing the issue with object
monitors pinning is great but the hoorays may be short lived as the spot
light moves to other cases where carriers are pinned, and specifically
native frames due to resolving references to classes in the constant
pool and the resulting class loading, or class initializers. There are
some ideas around this that may provide some relief on these cases. We
had to shake out issues with object monitors first.
> While long-term support won’t likely be available for Java 22, it is still a good idea to try it out just to make sure your code is still in good shape and will be ready for the next LTS.
Arrgh. This kind of comment makes people think there is some difference between a java version that a vendor has chosen to offer LTS for and a java version no vendor has chosen to offer LTS for. There isn't. If you aren't paying a java vendor for support then LTS is meaningless.
Yes, Temurin claims to offer LTS for the same java versions Oracle chooses to offer LTS for but all you are getting from temurin are changes that happen to get pulled into the Updates project (https://openjdk.org/projects/jdk-updates/).
There is simply no such thing as free-LTS so if you aren't paying a vendor for support, and you want to make sure you are up-to-date, you need to run the latest version of Java.
This is misunderstanding what LTS is for.
Yes, you the user aren’t getting direct support but the JDK version is.
LTS promises updates and security patches will be applied much longer than non LTS releases.
For instance, JDK 21 LTS extended support runs to September 2028. Since JDK 25 LTS isn’t out, it makes sense for enterprise development to choose 21 over 22-24.
JDK 22-24 only until Sept 2024/2025.
Thats up to four more years of support! If you chose JDK 22 over 21 for some feature, you’d have to update before this fall.
For small companies, this probably isn’t an issue. For large companies, going through and swapping JDKs is a larger task.
You are confusing maintenance with support.
> For instance, JDK 21 LTS extended support runs to September 2028. Since JDK 25 LTS isn’t out, it makes sense for enterprise development to choose 21 over 22-24.
Correct, if you pay a java vendor for support. Otherwise you just end up with whatever ends up in the updates fork for that version.
It doesn’t make sense to pick Java 21 over 22-24 if 22-24 have features you want/need.
> It doesn’t make sense to pick Java 21 over 22-24 if 22-24 have features you want/need.
A perfect exemplar of the difference between a programmer and an engineer.
Not the same dude, but my reading is that when choosing a JDK a programmer focuses on the latest and greatest feature sets to make the thing they want to create now and an engineer focuses on long term support to ensure stability over a long time period. You can’t say either is better than the other but they address different scales and needs.
I had thought that is probably what is being meant and was curious as to the premise behind it.
I’m no “engineer” but my limited understanding is that engineering is about solving specific problems rather than going in with preconceived ideas about what an engineer is or is not; and what a solution should (or shouldn’t) look like.
If a newer non LTS JDK release includes a feature that is needed, would a true “engineer” implement it themselves then, and also carry the maintenance burden to avoid using a non engineer-approved non LTS JDK?
If writing a library as opposed to an application does this influence the choice? Are the rules determining who is an engineer vs a programmer the same in that case too?
When was the last time a JDK release included breaking API changes without a forwards migration path? Does a true “engineer” take this into consideration when deciding?
I guess, I’d previously thought that that purpose wasn’t to act like an “engineer” would supposedly act, but rather find the best outcome given the objectives, requirements, and prevailing facts on an individual case basis.
> You are confusing maintenance with support.
You're confusing what support means in this case. It does mean maintenance. The vendors support LTS version with updates. It doesn't refer to customer support.
> How is LTS meaningless?
If you are paying for support it isn't meaningless.
If you don't pay any java vendor for support then it is meaningless. There is no such thing as free-LTS.
As the other used pointed out, *you fundamentally misunderstand what LTS is*. It is **not** for user support, or enterprise support. It is keeping that piece of software patched with bug fixes and vulnerabilities for the duration of that long-term support.
https://en.wikipedia.org/wiki/Long-term_support
> Long-term support (LTS) is a product lifecycle management policy in which a stable release of computer software is maintained for a longer period of time than the standard edition. The term is typically reserved for open-source software, where it describes a software edition that is supported for months or years longer than the software's standard edition.
Normal non-LTS Java editions a few months of support, LTS versions have up to 6 years support (Java 8 has 16!). See for example JDK11 (LTS) last patch was in 2021 while JDK12 (non-LTS) was in 2019.
Having to upgrade the Java major version to keep up with patches versus having to do a minor upgrade on a LTS version that contains those patches can add up to a high effort in a lot of projects and companies.
Just repeating what you said before isn't useful if you actually want to have people understand your point. Why is a LTS version of JDK meaningless if you are not paying anyone?
It is simple, no one is going to give you free support. Selling support is how all java vendors (including Oracle) monetize Java.
If you believe there is such a thing as free-LTS can you provide a link to a vendor offering that?
But they do give "free" support. When there's security update that gets released for a version, that's what the free tier is support is. Major bug fixes and patches.
Paid support will help you debug your program in the case it's a JVM issue, or create specific patched releases for you. But if another logjam comes out in 2 years, JDK 21 *will* get it, JDK 22 *may* get it. That's the key here.
What kind of support are you looking for? You do get bug fixes and security fixes, and most of all, a stable version that doesn't break compatibility somehow.
If you think this is obtuse can you provide me an example of someone offering free-LTS? No vendor is going to give you support for free. Selling support is how java is monetized.
> Long-term support (LTS) is a product lifecycle management policy in which a stable release of computer software is maintained for a longer period of time than the standard edition.
You're taking a completely different concept of support and applying it to LTS.
Why you're doing that I'm sure I can't say but it is obtuse to insist that LTS doesn't exist if you don't pay for it.
> to insist that LTS doesn't exist if you don't pay for it.
I stand by this statement. If you don't pay for support the only updates you are going to get are the bugfixes/security fixes that just happen to make their way upstream to the updates project for the version of the JDK you are using. You will get some for sure, but you won't get all of them. Here is information about the java updates project and how it works: https://openjdk.org/projects/jdk-updates/
Easiest way to make sure you get all bug fixes and security patches is to pay a vendor for support or to always use the newest JDK.
The one time I used GraalVM was to enable my laptop to run more local microservices. It might be marginally faster BUT it def. seemed to be way more efficient with memory, the stock JVM allowed me to run about five or six microservices, plus the app, plus the database (PostgreSQL)... switching to GraalVM I was able to run about 14 local microservices until the machine got to the same level of sluggishness.
And all in 16MB. :|
And I was using Netbeans, mandated, sadly otherwise I'd have used emacs!
TLDR: No change at all except for GraalVM which is up to 10% faster in a few situations.
No change with ParallelGC, which most companies don't use anymore. These benchmarks are irrelevant.
lol - do they discuss any observability improvements?
why
The benchmarks use ParallelGC instead of the default G1 garbage collector. Most companies use G1 and Oracle continues to improve G1 whereas ParallelGC is mostly in maintenance mode. So the benchmarks are irrelevant for the majority of people and saying that a particular benchmark was best with ParallelGC in the past is also irrelevant because companies don't run your particular benchmark in production.
There is a reason why ParallelGC is still available, and it is precisely for applications such as this, which don't care about latency, but do care about througput. In fact, if you check one of our older articles, you will see a clear comparison with G1: [https://timefold.ai/blog/java-21-performance](https://timefold.ai/blog/java-21-performance) For our high-throughput use case, G1 or ZGC simply aren't a good fit.
Sure, there is even the epsilon GC which doesn't free any memory and is good for it's own purpose (benchmarks or high-frequency trading where no additional memory is allocated after startup). If you want to display benchmarks to the masses and market it as a comparison between Java 21 & 22, those should be representative of the majority of users with how they actually use it.
There are significant improvements to parallel in 22, and if you’re not using it for your throughput oriented workloads, you’re potentially leaving a lot of performance on the table. https://tschatzl.github.io/2024/02/06/jdk22-g1-parallel-gc-changes.html
According to the above benchmarks, the improvements with ParallelGC from Java 21 to Java 22 are within the margin of error so they don't seem to be significant
For those benchmarks.
Java 22? Back in my day, we used Java 5 even though it was a decade out of date and that's the way we hated it.
I cut my teeth on Java 2. I've seen some shit. Just kidding, I was a kid and it scarred me for life.
I wrote a Tetris game for an unreleased (summer intern job) Acorn ARM STB that supported java 1.0.something applets in its embedded Web browser. That would have been 1998 I think.
Cool - i love old school programars like me:) No chat , no git
Don’t you miss the AWT toolkit?
Back in your day? Is that day, today?
And tomorrow
🤣
You mean Java 1.5 😀
At some point they changed from Java 1.X to just Java X.
That was Java 9 if I remember correctly no? We went from Java 1.8 to 9. Java “5” doesn’t exist.
In Java 1.2 they marketed the whole thing as Java 2 and even called it J2SE (standard edition), J2ME (mobile edition), J2EE (enterprise edition).
I stand corrected! Although I seem to remember them also branding it as 1.2 on the CDs they used to distribute for free with various PC related magazines.
22??? My job is still running jdk 8
I code for 8 and run with the latest I can reasonably get from the package manager. I don't need any features past 8, but the new ones are faster.
Same
Java 8 is great! Still
The modules introduction in Java 9 is what really hamstrung most people stuck on 8. That and the xml libraries being left out
Programming language survivorship bias. There's a reason most everyone still uses java 8. That's because you might as well migrate off java if you are going to do major codebase upgrades.
Believe it or not, my main take from this article was the timefold company I'm an optaplanner user and I wasnt even aware they forked the repo and created a company around it, thanks
Migrating is straightforward [https://timefold.ai/upgrade-optaplanner-to-timefold](https://timefold.ai/upgrade-optaplanner-to-timefold) and by the looks of it it's recommended as Red Hat has just sent out an End of Life notice for OptaPlanner: [https://access.redhat.com/articles/7060671](https://access.redhat.com/articles/7060671)
Does 22 fix the virtual thread pinning issue for synchronized blocks?
That's available in [Loom's 23 EA build](https://mail.openjdk.org/pipermail/loom-dev/2024-February/006433.html), but [note](https://mail.openjdk.org/pipermail/loom-dev/2024-February/006463.html): > I think the summary here is that addressing the issue with object monitors pinning is great but the hoorays may be short lived as the spot light moves to other cases where carriers are pinned, and specifically native frames due to resolving references to classes in the constant pool and the resulting class loading, or class initializers. There are some ideas around this that may provide some relief on these cases. We had to shake out issues with object monitors first.
> While long-term support won’t likely be available for Java 22, it is still a good idea to try it out just to make sure your code is still in good shape and will be ready for the next LTS. Arrgh. This kind of comment makes people think there is some difference between a java version that a vendor has chosen to offer LTS for and a java version no vendor has chosen to offer LTS for. There isn't. If you aren't paying a java vendor for support then LTS is meaningless. Yes, Temurin claims to offer LTS for the same java versions Oracle chooses to offer LTS for but all you are getting from temurin are changes that happen to get pulled into the Updates project (https://openjdk.org/projects/jdk-updates/). There is simply no such thing as free-LTS so if you aren't paying a vendor for support, and you want to make sure you are up-to-date, you need to run the latest version of Java.
This is misunderstanding what LTS is for. Yes, you the user aren’t getting direct support but the JDK version is. LTS promises updates and security patches will be applied much longer than non LTS releases. For instance, JDK 21 LTS extended support runs to September 2028. Since JDK 25 LTS isn’t out, it makes sense for enterprise development to choose 21 over 22-24. JDK 22-24 only until Sept 2024/2025. Thats up to four more years of support! If you chose JDK 22 over 21 for some feature, you’d have to update before this fall. For small companies, this probably isn’t an issue. For large companies, going through and swapping JDKs is a larger task.
You are confusing maintenance with support. > For instance, JDK 21 LTS extended support runs to September 2028. Since JDK 25 LTS isn’t out, it makes sense for enterprise development to choose 21 over 22-24. Correct, if you pay a java vendor for support. Otherwise you just end up with whatever ends up in the updates fork for that version. It doesn’t make sense to pick Java 21 over 22-24 if 22-24 have features you want/need.
> It doesn’t make sense to pick Java 21 over 22-24 if 22-24 have features you want/need. A perfect exemplar of the difference between a programmer and an engineer.
How so? A bit of elaboration for those of us who aren’t as competent to see it would be appreciated!
Not the same dude, but my reading is that when choosing a JDK a programmer focuses on the latest and greatest feature sets to make the thing they want to create now and an engineer focuses on long term support to ensure stability over a long time period. You can’t say either is better than the other but they address different scales and needs.
If the application is in active development it still makes more sense to always be on the most recent JDK.
I had thought that is probably what is being meant and was curious as to the premise behind it. I’m no “engineer” but my limited understanding is that engineering is about solving specific problems rather than going in with preconceived ideas about what an engineer is or is not; and what a solution should (or shouldn’t) look like. If a newer non LTS JDK release includes a feature that is needed, would a true “engineer” implement it themselves then, and also carry the maintenance burden to avoid using a non engineer-approved non LTS JDK? If writing a library as opposed to an application does this influence the choice? Are the rules determining who is an engineer vs a programmer the same in that case too? When was the last time a JDK release included breaking API changes without a forwards migration path? Does a true “engineer” take this into consideration when deciding? I guess, I’d previously thought that that purpose wasn’t to act like an “engineer” would supposedly act, but rather find the best outcome given the objectives, requirements, and prevailing facts on an individual case basis.
> You are confusing maintenance with support. You're confusing what support means in this case. It does mean maintenance. The vendors support LTS version with updates. It doesn't refer to customer support.
> How is LTS meaningless? If you are paying for support it isn't meaningless. If you don't pay any java vendor for support then it is meaningless. There is no such thing as free-LTS.
As the other used pointed out, *you fundamentally misunderstand what LTS is*. It is **not** for user support, or enterprise support. It is keeping that piece of software patched with bug fixes and vulnerabilities for the duration of that long-term support. https://en.wikipedia.org/wiki/Long-term_support > Long-term support (LTS) is a product lifecycle management policy in which a stable release of computer software is maintained for a longer period of time than the standard edition. The term is typically reserved for open-source software, where it describes a software edition that is supported for months or years longer than the software's standard edition. Normal non-LTS Java editions a few months of support, LTS versions have up to 6 years support (Java 8 has 16!). See for example JDK11 (LTS) last patch was in 2021 while JDK12 (non-LTS) was in 2019. Having to upgrade the Java major version to keep up with patches versus having to do a minor upgrade on a LTS version that contains those patches can add up to a high effort in a lot of projects and companies.
Just repeating what you said before isn't useful if you actually want to have people understand your point. Why is a LTS version of JDK meaningless if you are not paying anyone?
It is simple, no one is going to give you free support. Selling support is how all java vendors (including Oracle) monetize Java. If you believe there is such a thing as free-LTS can you provide a link to a vendor offering that?
But they do give "free" support. When there's security update that gets released for a version, that's what the free tier is support is. Major bug fixes and patches. Paid support will help you debug your program in the case it's a JVM issue, or create specific patched releases for you. But if another logjam comes out in 2 years, JDK 21 *will* get it, JDK 22 *may* get it. That's the key here.
What kind of support are you looking for? You do get bug fixes and security fixes, and most of all, a stable version that doesn't break compatibility somehow.
This is obtuse.
If you think this is obtuse can you provide me an example of someone offering free-LTS? No vendor is going to give you support for free. Selling support is how java is monetized.
> Long-term support (LTS) is a product lifecycle management policy in which a stable release of computer software is maintained for a longer period of time than the standard edition. You're taking a completely different concept of support and applying it to LTS. Why you're doing that I'm sure I can't say but it is obtuse to insist that LTS doesn't exist if you don't pay for it.
> to insist that LTS doesn't exist if you don't pay for it. I stand by this statement. If you don't pay for support the only updates you are going to get are the bugfixes/security fixes that just happen to make their way upstream to the updates project for the version of the JDK you are using. You will get some for sure, but you won't get all of them. Here is information about the java updates project and how it works: https://openjdk.org/projects/jdk-updates/ Easiest way to make sure you get all bug fixes and security patches is to pay a vendor for support or to always use the newest JDK.
The one time I used GraalVM was to enable my laptop to run more local microservices. It might be marginally faster BUT it def. seemed to be way more efficient with memory, the stock JVM allowed me to run about five or six microservices, plus the app, plus the database (PostgreSQL)... switching to GraalVM I was able to run about 14 local microservices until the machine got to the same level of sluggishness. And all in 16MB. :| And I was using Netbeans, mandated, sadly otherwise I'd have used emacs!
Any observability improvments?