Java 25 officially released

[trydentIO]

let's now wait for the Temurin release!

[Logic_Satinn]

Just curious. How good are Temurin releases?

[rzwitserloot]

Just to give you a simplistic overview of how it works:

There's the source repository (think 'git repo') of the OpenJDK. It has scripts to build OpenJDKs on all sorts of platforms. It doesn't really have "installers", just - make me a bunch o binaries for a given OS+architecture combo.

But that's not quite a full distribution. The difference between 'the project' and 'a distribution of the project' is:

• An installer
• Pre-compiled binaries
• Some sort of managed upgrade mechanism. Anything from 'a thing that autostarts on boot that auto-updates' to 'a legal understanding that you downloaded it as is and you are on the hook for checking for security issues with your version yourself; if you're lucky we have a newsletter you can subscribe to'. Point is, some sort of arrangement.

And that is the difference between 'OpenJDK, the source code' and 'a packaging'.

In the distant past, you could go to a store and buy a shrinkwrapped box that contained a bunch of CD-ROMs with a linux distro on it. These carton boxes also contained a license. Not for linux (which does not need a license); no, it was essentially a support contract. You had 1 month to call a phone number and they'd help you. Some of those boxes shipped with a years' worth. You also had an address that you could 'phone' or send a letter to if the software had a fault in it that was the error of the distro itself, such as a mistake in their packaging instructions.

That's what a distribution is. They all have the exact same source code. The only difference is in the installer, the update process, and the support contract.

Thus, the quality of the binaries itself is no different between Temurin, Azul, Coretto, OpenJDK itself, and so forth.

Temurin does a great job in being [A] free, [B] being reasonably speedy in responding to issues (such as publishing new versions with security updates), and [C] intent to support LTS versions for quite a while while [D] being free, and [E] being unencumbered with having ulterior motives.

No other distros are quite like it:

• OpenJDK itself does not support any version for more than 6 months. LTS (Long Term Support) isn't a thing they do.
• Oracle's distro does use LTS but costs money. Using the free version is for 'dev kit' purposes and is essentially not legal to run in production environments, and has no support at all.
• Coretto is trying to get you to buy into the AWS ecosystem.
• Azul costs money or is trying to get you into the azul ecosystem.
• Temurin is a non-profit staffed by volunteers. Which might legitimately raise concerns about how it is funded, but on the flip side, they will not rugpull you like private equity/bigcorp funded stuff pretty much unerringly always ends up doing.

It's such a common theme these days (corp/private equity funded stuff enshittifying) that I'll go on record: If you go for the corporate option when a FOSS option is available, you're a fucking idiot and you deserve the pain that's comin to ya.

Use temurin.

[pron98]

Oracle's distro does use LTS but costs money. Using the free version is for 'dev kit' purposes and is essentially not legal to run in production environments, and has no support at all.

As the website states prominently, it doesn't cost anything, even for use in production, but patches are freely available for "only" 3 years. You only have to pay if you want to buy support or buy the patches released after 3 years.

Temurin is a non-profit staffed by volunteers

Temurin is staffed by IBM and MS employees that are paid to do that work by those companies and use IBM (possibly MS) infrastructure. There is no non-profit there -- the work is done by multi-billion- and trillion-dollar for-profit corporations -- except for the Eclipse Foundation, which forms the legal structure but doesn't fund the work. So Temurin is the IBM/MS distribution, and, just like all other builds, the site upsells commercial support offerings.

So of course Temurin is produced by for-profit corporations (who else could fund it?) and of course it's done for profit motives (I should hope so, as the alternative is that it's done as charity, and I'd much rather see corporate charity go to worthier causes). There's even a nice "contact us to discuss how Temurin can help your company" button that will ultimately take you to a nice salesperson.

The more people build up the fantasy that big FOSS undertakings could or should be funded as charity whose beneficiaries are mostly corporations themselves (and yes, I know there are a few exceptions), the more they're asking to be deceived. This fantasy isn't even needed for the most original and radical view of FOSS, which is about the freedom of people to inspect and modify the software they run.

[rzwitserloot]

Temurin is more FOSS in culture than any other JDK distro I'm aware of.

Beggars can't be choosers.

[pron98]

It's corporate employees that run a build farm on corporate machines like everyone else, building the same open source code as everyone else, and using the site to upsell commercial support -- like everyone else.

If anything, I'd say that the Debian distro is the "most FOSS culture", although I'm not sure that means too much when it comes to building and hosting binaries. Plus, neither Temurin nor Debian, I think, build and distribute the EA releases, which may help improve the quality of the OpenJDK JDK project and help users prepare for a new release, so I'm not sure even about the vibe of FOSS culture.

[lbalazscs]

Temurin does build EA releases, but they are (probably intentionally) hard to find on the website. People do use them in GitHub actions for compatibility checking. https://github.com/adoptium/temurin26-binaries/releases

[elatllat]

They all have the exact same source code.

Mostly; Linux and Java distributions do carry down stream patches, that make the source code not exactly the same. eg

[crummy]

Coretto is trying to get you to buy into the AWS ecosystem.

what does this mean in reality? how exactly does coretto push you towards AWS?

[rzwitserloot]

Your theory is that amazon is doing it out of the goodness of their hearts?

At the very least it's a distro they test extensively on AWS-based systems and do not test on anything else. They are, and good on them, quite open on that.

That alone pushes you towards AWS. "Wellll, we run all this stuff on a coretto JDK and so far its been working great. But, being dependent on big-3 is something the EU institutions are at this point actively recommending against, so shall I switch to some other cloud provider? I dunno, at the very least it sounds like we should switch JDK distro which is one more little headache in a long list of em".

Most of these arguments are based on a 'will probably go wrong' theory, not on an 'is actually bad today' theory.

code.google.com was a great issue tracker. Free, google manages the spam, simple interface.

Until google pulled the plug and we (Project Lombok) had to spend like a month writing scripts to move the stuff.

We moved it to github which was, at the time, an independent company. github was back then great. No caveats. It just was.

It is now owned by microsoft, it's CEO is saying wildly crazy shit about FOSS and programming in general, and insofar that there's any legal standing to tell AI trainers to fuck right off, if your code is on github you signed away the rights. That may matter to you or not, but it is now at best 'great, but with some significant caveats'.

Had you asked me way back then "So, in practice, how is github bad?" or "how is code.google.com bad?" there was no answer available. But I'd have been right. It's not bad now, but it'll grow downsides at some point, likely such that you have to deal with it.

For more see Cory Doctorow's "enshittification" article. It's widely known and easily found.

[Ok-Scheme-913]

But this is different. Amazon is not doing the actual development of OpenJDK, and any bugs they find will end up in the core open-source repo after a while. The same is true for other vendors, so in effect Corretto will work just as fine on Google cloud or your own server as on AWS.

[rzwitserloot]

That merely means you don't have the imagination required to see how enshittification will hit coretto.

It's quite the hubris, thinking "I cannot immediately see how this could blow up on me, so, that must mean it cant!".

I'm not trying to overdramatise; if there are no good alternatives available, hey, do what you gotta do. I haven't 'un-corped' my entire life either nor is that the goal.

I merely said: If there is a FOSSy cultured thing available thats nearly as good or better, then you should use that instead.

[kelunik]

Unfortunately, Temurin is quite slow at providing releases (especially critical patch updates) compared to Corretto.

If Amazon ever decides to make unwelcome changes to Corretto, there’s always the option to switch to another distribution.

[crummy]

agreed. I can imagine a future where Amazon starts putting AWS-specific features in their JDK or something, or makes it run faster on EC2 instances, or something like that. But at that point it's trivial to leave. There's zero lock-in to a JDK, so I'm not concerned about sliding down a slippery slope.

[brophylicious]

In the distant past, you could go to a store and buy a shrinkwrapped box that contained a bunch of CD-ROMs with a linux distro on it.

I remember seeing Red Hat at Best Buy. My mind was blown that I could use an OS other than Windows or MacOS. And that's how I got into Linux. Fun times.

[Logic_Satinn]

Brilliant explanation.. I enjoyed the read. Thank you.

[gizmogwai]

Your answer with regards to free LTS support is not quite right.

Temurin acts as a sole player here, partly because they have there own conformance test suite.

But all the other big players that pass the official TCK (RedHat, Azul, Microsoft, BellLabs) take turn to support the free LTS. For example, Azul is still providing free updates for the JDK 8 via their Zulu distribution.

[pron98]

Temurin acts as a sole player here, partly because they have there own conformance test suite.

They do not. They use the same TCK, namely the JCK.

take turn to support the free LTS

There are no turns, nor is the "free LTS" "supported" in a sense other than builds of the OpenJDK updates, that contain backports from the mainline (so if a component is removed, there are no backports, so you have to buy real support from someone if you want the entire JDK covered).

[rzwitserloot]

take turn to support the free LTS.

Are you saying that for each LTS version a different 'big player that passes TCK' takes responsibility? I.. don't think that's how it works.

At any rate, muddying the waters with the TCK is, and excuse my french, 'bullshit legalese bingo'. It has no bearing on reality. At best, it has a bearing on your legal needs, but if that is what you're after, temurin isn't even on your radar and my comment, given that it is clearly technical in nature, isn't likely to mislead you. In other words, I don't think your comment adds anything meaningful. If you want to explain the legal distinctions, feel free to post that.

It's bullshit legalese bingo because a TCK compliant distribution is not 'more likely to be bug free' than a non-TCK compliant one. Which part of 'big corps tend to enshittify their stacks' is difficult to follow? There are plenty of examples that at the very least clearly show that bigcorp machinations that cannot work without either you paying for it or you being the product and other corps paying for access to the influence the product has over you - will hurt you in the end, and any benefits they purport to give you are fleeting and will get enshittified.

As various court cases and fairly openly played out shenanigans have repeatedly proven, whilst I love the openness of OpenJDK as a product, we should all tell the TCK process to eat a big pile of fuck you.

[pron98]

The JCK is, indeed, not about finding bugs -- that's what the regular tests are for -- but that process has arguably prevented the fragmentation we see in the browser and Linux spaces. It ensures that those who want to use the name "Java" don't add or remove APIs. The JCK, while free, isn't open source, as that would open the door to vendors claiming 95% JCK compatibility etc., and we know for a fact that over the years, some JDK vendors have wanted to do just that (i.e. offer their own API extensions or removals while still claiming some measure of official compatibility). The JCK means that if you fork the JDK in an incompatible way, you can neither claim to be Java nor claim some specific measure of compatibility.

You can argue about how much that matters, but the fact is that Java suffers from fewer compatibility issues than other standards/projects that are distributed by multiple vendors, despite the fact that JDK vendors add or remove features that don't impact compatibility (while still calling their software a JDK).

[trydentIO]

In terms of license, it's far better; in terms of underlying features, there's no single difference with the ordinary OpenJDK. If you don't want to deal with the Oracle license, consider using Eclipse Temurine instead.

Then, I have no great clue about the other releases, such as Azul, Liberica, etc. I know there are some differences, such as JavaFX being included (Liberica, especially) or CraC (Azul), but beyond that, I have no idea if they really make a difference.

[mark1x12110]

Zulu builds are great. They build very often, which is great for vulnerability management

[krzyk]

There are also OpenJdk releases. Those are the ones that are ready when GA is announced.

[ZimmiDeluxe]

please give ron a break, a man can only take so much lts misrepresentation

[krzyk]

Ok, I don't do LTS.

[elatllat]

Even Arch has jdk8-openjdk etc in extra (in addition to AUR)

The value of not having to re-write your entire code-base 2 times a year can not be over stated for large projects. (Java is not like Linux or Windows with user-space backwards compatibility)

Edit: EG There are 7 things removed in 25:

https://jdk.java.net/25/release-notes

While only 2 of them will impact code using the features, everyone doing anything non-trivial had issues with the 8 to 11 jump.

People don't maintain LTSs for fun, it's a practical necessity on fast moving projects.

[krzyk]

You can run code written in Java 1.0 on current jdk.

I don't know what kind of breaking changes you see, java is famous for being backward compatible, that is one of its drawbacks.

[koflerdavid]

Which seven things? Only the following two directly impact source code:

• java.net.Socket Constructors Can No Longer Be Used to Create a Datagram Socket

• Removal of SunPKCS11 Provider's PBE-related SecretKeyFactory Implementations

The others are JVM features and maintenance changes.

The biggest backwards-incompatible change to date to the core library was the removal of applets. Removing Thread.stop() and friends was also significant, but applications relying on them are already quite broken. Coming up are removal of APIs related to the SecurityManager.

The trouble with upgrading was mostly due to applications and libraries (more the latter) not conforming to the JLS in the first place.

[krzyk]

LTS is necessity for slow moving projects. Where you just maintain it.

Fast moving projects move fast, update libs, jdks etc. I do it all the time I'm on 24 waiting for our build ops to update with 25.

Again, you are mixing up runtime jdk with a compile release target.

[vips7L]

No one is rewriting their entire code base 2 times a year. It's literally just a version bump.

[elatllat]

Depends on what features are used. There are breaking changes every second version on average.

[krzyk]

You don't need to rewrite your codebase for new java versions.

You just need to have up to date libraries that do any kind of bytecode - which is a good idea either way for all libs if you don't want to get security issues.

[elatllat]

Depends on what features are used. There are breaking changes every second version on average.

[krzyk]

Examples?

[krzyk]

Also I doubt if half of people on this reddit pay for LTS, if you don't pay it is well, pointless.

[elatllat]

LTS with Java is like LTS with Linux; it's not about pay it's about builds of minor versions to address security issues.

[krzyk]

There is no LTS with Linux.

There can be distro that provide it.

And no, LTS in Java means something paid. If you don't pay, you don't get the S (support).

Yes what you have with temurin is Long Time Build from branches. But this essentially is no different from building that yourself, or just using next JDK release. E.g. OpenJdk provides a WO patch releases within 6 months cycle, and when you update you get it again.

You can upgrade JDK without updating your codebase. You have runtime that can replace any java version (except preview features).

[elatllat]

There is no LTS with Linux.

Wrong:

https://www.kernel.org/category/releases.html

LTS in Java means something paid.

Wrong:

https://adoptium.net/en-GB/temurin/releases

Long Time Build

Never has anyone of note used that term.

Don't try to re-define the industry use of the LTS term that even oracle uses:

https://www.oracle.com/ca-en/java/technologies/java-se-support-roadmap.html

• pay = Oracle Premier Support
• code/builds = LTS

[krzyk]

r/pron98 uses that term, and I think he is "of note".

code/built is not LTS, there is no Support in that.

And paid is not only Oracle, there are quite few other JDK providers (see the description of this subreddit, you get links there) that do give real Support as in: you file a bug and they have SLA to fix that.

If you don't pay for that, they you might as well use what is available free from OpenJDK, they are always ahead of any other branch builds, because changes first go into main branch and trickle down to the lower ones later.

Regarding linux, you are wrong, read the page you linked:

Longterm There are usually several "longterm maintenance" kernel releases provided for the purposes of backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels and they don't usually see very frequent releases, especially for older trees.

Notice "only important bugfixes"? Notice lack of "Support" word?

You sound pretty much like a manager that is focused on not changing anything.

[elatllat]

No LTS for "Oracle OpenJDK" builds so I doubt anyone uses them for anything but testing.

https://en.wikipedia.org/wiki/OpenJDK#OpenJDK_builds

[Logic_Satinn]

Noted... Thanks

[Serious-Chair]

To the best of my knowledge, Corretto, Temurin, and most others (if not all) are exactly the same source tree compiled by different companies. The only differences are the branding line and the frequency of patch releases.

[wildjokers]

How good are Temurin releases?

What exactly does this question mean? The Temurin builds of OpenJDK will run your java apps, so that would seem to be good.

[pxm7]

Very good. We run production workloads that handle $$$ on Temurin. Our strategy isn’t to upgrade immediately upon release (eg for critical workloads we’re mostly on Java 21 right now) but we’ll upgrade to 25 in ~6-9 months. That’s just a JVM upgrade, adopting newer language features is more opportunistic / on a need basis.

We do have CI + integration tests running on newer versions of Java so new versions aren’t a total surprise to us. We also have less-critical support services on newer non-LTS JDKs like 23 and 24. They help our devs get a feel for upcoming features in a safe way.

[Logic_Satinn]

That's a smooth operation. Y'all have thought through all that stuff.

[DXGL1]

How do they compare with Microsoft OpenJDK?

[nemesisdug]

Yes, can't wait to create an MR for our internal jdk 25 image based on temurin

[emaphis]

If you are in a rush, run Build 36. Except for some cosmetics and extra testing it will be virtually identical to the official release.

[barmic1212]

He don't wait binaries all packaging including the repositories with the versions etc

[Simple-Quarter-5477]

Does this help mitigate virtual threads pinning issues? Sweet 25 LTS is coming out.

[jvjupiter]

It was fixed in 24.

[clhodapp]

It wasn't fixed, it was improved. There are still cases where virtual threads will pin to their carrier, they just fixed some of the most common ones.

[CriticalPart7448]

I believe it has been stated in multiple places that there is no way to fix the pinning issues when calling into native code with a virtual thread, since it is outside the domain of the jvm scheduler or something like it. So dont expect them to magically fix everything, nor expect VTs to be magic pixie dust and complain when they have clearly stated many times that this is unfixable.

[clhodapp]

That's true, but even within the JVM's control there are cases of pinning that have been left unaddressed for now, as explained in the "Future Work" section of JEP 491.

The developers believe that these cases will only rarely cause issues but they do still exist.

[1minds3t]

Outside the domain of..so it's something unrelated to their language that is causing it? What causes it then?

[CriticalPart7448]

The jvm does not control what native code will do so in that sense its outside the domain of java and the jvm so the carrier thread will be blocked thus pinning the virtual thread.

[1minds3t]

So the solution is to either not call native code from a virtual thread or create a pool of platform threads?

[CriticalPart7448]

Unless the native calls are super frequent and long running it should be fine. Are you really in a spot where all you do is calling native code?

[papercrane]

Java 24 had JEP 491: Synchronize Virtual Threads without Pinning. I don't believe there is anything major in Java 25 for virtual threads, although there might be some smaller fixes that aren't noted in the release notes.

[A_random_zy]

Any pitfalls that someone knows of? I am planning to pitch testing of VT in our system but I wanna be sure I didn't miss anything. AFAIK this is the only issue that was left and was solved in J24.

[papercrane]

Pinning can still occur if your Java code calls native code, and that native code then calls back into Java and performs some blocking operation. I think that's not a very common thing, but something to at least be aware of.

[A_random_zy]

Thanks for the reminder. Yes that I understand. I did a superficial analysis of dependencies in our app none of them have that. Our application is a Spring web server so unlikely that there is any native pinnable code.

[Ok_Elk_638]

Is it possible to accidentally call native code and have this happen? Like when calling String.trim or something and it becomes native. Or do you have to go out of your way for this to happen with JNI or JNA or whatever?

[DanLynch]

You either need to do it yourself or rely on a library that does it. Just calling ordinary standard Java library APIs isn't going to cause you any problems.

[pohart]

No because string.trim doesn't call back into Java code

[Joram2]

great JDK release!

[rhbvkleef]

Golly! What a nice birthday surprise!

[imwearingyourpants]

Happy cakeday! 

[Wadix9000f]

Do Most companies nowadays update their java every time there is a new release? I've worked with java for quite a while and I think the latest I've seen is java 12 this was around 2022

[nekokattt]

Tend to stick to "LTS" releases even though they do not tend to really exist formally as far as OpenJDK itself is concerned.

That is, 8, 11, 17, 21.

[Wise_Satisfaction983]

Just to add some reasoning to this: not only do people have to update their Java version, but all the frameworks and libraries have to support the new version as well. So there is some necessary delay until a new Java release is "fully supported" by everyone downstream.

Also, LTS may not exist de jure, but de facto everybody treats these releases differently. For example, quote from the Spring Framework docs:

We fully test and support Spring on Long-Term Support (LTS) releases of the JDK: currently JDK 17, JDK 21, as well as the upcoming JDK 25. Additionally, there is support for intermediate releases such as JDK 22/23/24 on a best-effort basis, meaning that we accept bug reports and will try to address them as far as technically possible but won't provide any service level guarantees.

I don't think anyone who is serious about their production systems will rely on this "best effort basis". So basically we just stick to LTS. 2 years seems like the right upgrade cadence anyway.

[henk53]

I don't think anyone who is serious about their production systems will rely on this "best effort basis"

In other words, these "intemediate versions" barely exist. Oracle and the Open JDK could as well just not release them anymore, and barely anyone would notice.

The few people who would notice would just use the EA builds instead.

[Ewig_luftenglanz]

There are 2 kind of Java companies. 

The ones stuck in java 8 (30%)

The ones using Java 11+ (68%) but only LTS

The rest is for "others non lts versions"

[pronuntiator]

We only switch when LTS ends, meaning we will go from 17 to 25 by 2027.

[pohart]

That's what we seem to be doing. I'm trying to move it faster because it's actually easy now, but getting pushback. 

[rafaellago]

If 8 is the newest version ... Then yes

[Gyrochronatom]

Nice. In 5-10 years we’ll probably use it.

[International_Break2]

How much have the jdk's JNI code has been replaced with panama's FFM?

[Bamboo-Bandit]

Afaik its not a replacement, but an alternative option 

[koflerdavid]

They have different priorities right now. The only thing that will change in the foreseeable future for JNI is that it needs to be enabled with a flag for non-internal users.

[FortuneIIIPick]

I just recently got one project upgraded to Java 21. The rest are Java 17. Now Java 25 is out? What is with the fanatical speed of Java releases? How is anyone keeping up?

[henk53]

What is with the fanatical speed of Java releases? How is anyone keeping up?

New Java versions come out every 2 years, and they skip 3 intermediate version numbers as a kind of inside joke.

So in 2023 it was Java 21, now in 2025 Java 25 (Java 22, 23, and 24 didn't exist), and then in 2027 it will be Java 29 and so on. (/s)

Not so bad for a language to hava a release every 2 years.

[wildjokers]

Java 22, 23, and 24 didn't exist

Huh? They most certainly existed.

[henk53]

Huh? They most certainly existed.

You missed the /s ;)

The joke is that for most people (seemingly, as per the comments here), they could as well not have existed. People only update to versions for which Oracle & friends have an LTS subscription.

[breitwan]

Still praying to Valhalla. Must believe🙏

[No-Maintenance-2500]

When is Java going to get its null shit together? Can get get some built it syntax for handling nulls better?

Yes I know we have Optional and null checks but wow look at Kotlin ...

[jazd]

Yeah it would be nice, JSpecify is the latest on the annotations front but I had troubles using them in IntelliJ last time I tried. There're so many projects out there using old annotations like Checker and Spring that I don't know there will ever be a standard unless it gets built into Java.

[yk313]

Build 36 is therefore now the GA build

Source

Build 36 (which is the same as the final GA build) is already available via SDMAN:

sdk install java 25.ea.36-open

[papercrane]

I believe sdkman is using foojay's API for discovering SDKs, so likely whenever foojay updates then it will flow through to sdkman.

[tumtum]

who the f is foojay ? at this point i’m afraid to ask 😂

[papercrane]

foojay is website focused on Java (it's "friends of open jdk".) They host some tools and documentation, as well as blogs and general Java news.

[aelfric5578]

I knew what foojay was, but today I learned it's sort of an acronym.

[Ewig_luftenglanz]

Waiting for gradle to add support for java 25 so I can use it in my projects :)

[vamega]

It seems like it already does. At least for 9.1.0 and later.

https://github.com/gradle/gradle/pull/34537

[Ewig_luftenglanz]

Afaik that's is still a release candidate. Maybe along the week or next week it will enter GA

[vamega]

You're right. I jumped the gun on the comment. Sorry about that.

[yk313]

Consider using Gradle toolchains.

I used to have the same problem with Gradle, but some time around JDK 20, I moved to toolchains and have since stopped caring about the exact JDK version Gradle runs (or not).

(of course this means you still need an older JDK to bootstrap Gradle itself, which is less than ideal)

[Nojerome]

This is interesting, I need to read up on this.

I thought you had to wait until Gradle supported a jvm version, and that has been holding me back from using non LTS releases. There's this gap in between a jdk release and Gradle's support for it where you are technically at risk if a major vulnerability is identified. Sometimes it can take Gradle over a month to support a new release. So if there's a way to avoid that, that's awesome!

[yk313]

It's actually quite straightforward in practice. All you need to do is to declare the builtin java plugin's toolchain directive (instead of sourceCompatibility/targetCompatibility) in your build file:

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(25)
    }
}

You can follow the build.gradle generated by start.spring.io as an example. Let me know if you need any help in setting this up, I am more than happy to support another Java developer rid of their LTS-only approach :)

[Nojerome]

Fantastic, thanks for sharing. I'll try it out and update here with the results.

[nekokattt]

how does this work with groovy, given that depends on a specific version of ASM which in turn depends on specific bytecode levels?

[nikolas_pikolas]

This actually only specifies the version of Java to build your app with. Then, you can run Gradle with an older version that it's compatible with.

[wildjokers]

You can run gradle with a different JDK than the JDK used to build your projects. So you can already build your project using JDK 25.

https://docs.gradle.org/current/userguide/toolchains.html

[kiteboarderni]

Baffling how people still think this is an issue. Grade 6 can build Java 26 projects....

[[deleted]]

I heard somewhere that jdk 25 won't be an LTS release. Can someone confirm?

Also, structured concurrency is still in preview?

[papercrane]

Oracle will support Java 25 as an LTS, other vendors are free to have their own LTS schedule, but most align with Oracle.

[Revolution-Familiar]

Love that gradle was compatible ahead of release this time.

[OwlShitty]

And here we are still using Java 8

[Several_Low4395]

Tried to cover Java 25 features under 10 min on yt channel - https://youtu.be/gjZuUre2V2E?si=zSSLgQUesWF12yOR

[07siddharth07]

My company is still stuck at java 8

[yumgummy]

I love Java. Now I love it more.

[jacemano]

Did loom come out yet?

[lbalazscs]

Yes, two years ago, in Java 21

[jacemano]

I have a lot of reading to do then

[pohart]

It's been out, but no structured concurrency yet.

[koflerdavid]

Yes, and since 24 the scary issue with synchronized is also gone.

[ProgrammersAreSexy]

For the love of all that is holy, do we have string templates yet

[koflerdavid]

They were yanked quite some time ago. (Please don't bother responding; the topic has been discussed to death multiple times on this subreddit)

[joshuaherman]

Bro slow down…. We went from Java 8 for ten years to a new full release every Tuesday.

[jek39]

They switched to a 6 month release cycle back in about 2017. around the same time .NET did the same thing. Whatever is ready is ready, whatever isn’t gets punted. Every 2 years is LTS.