It sounds like a good idea, but I can imagine lots of downstream breakage, some of it not immediately obvious, with apps that make bad assumptions.

Edit: The risks section of the linked doc above does explain some of that, and there is some notable risk.

You're not wrong, which is probably why they did it in this release.

JDK 17 was an LTS release, and 18 isn't. The next LTS will be JDK 21 in September 2023:

* https://www.oracle.com/java/technologies/java-se-support-roa...

This presumably gives folks times to adjust before jumping between LTSes in production.

It's an Oracle term, and I expect the majority of OpenJDK committers and decision-makers are still from Oracle.

It's a thriving ecosystem (which is great!) but yes, Oracle does contribute a significant portion [3].

[1] https://mreinhold.org/blog/forward-faster [2] https://mail.openjdk.java.net/pipermail/discuss/2017-Septemb... [3] https://inside.java/2022/03/22/the-arrival-of-java18/

E.g. look on the things introduced in JDK 16 and JDK 17.

LTS is a good gimmick for decision makers in companies, but developers also don't care about it (it is not LTS as in e.g. Ubuntu).

It doesn’t mean enabling Java 18 on Production on day 1, but certainly it means adding a Java 18 compiler to your CI, running tests using Java 18, etc.

[1] https://www.reddit.com/r/java/comments/o0m6g8/the_state_of_p...

Even if you don't use any of the new features, there may be deprecation warnings and such that one should be aware of sooner rather than later. Tweaking early to ensure compatibility with current-LTS and future-LTS versions is worth some cycles: if you don't, you'll pay for it eventually when old(er)-LTS is inevitably retired.

I get that not everyone has spare time and energy, but it doesn't take that long to grab a beta, put it on a device (or load up the simulator) and find out. Leaving it until the last minute just forces you into a panic, and seems irresponsible when you had months to just test your product.