5 ms·
> 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. You're no
by throw0101a 5y ago
> 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.
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-roadmap.html https://www.oracle.com/java/technologies/java-se-support-roa...
This presumably gives folks times to adjust before jumping between LTSes in production.
- toyg 5y agoWe like to give Oracle stick (and rightly so) but this is rolling/LTS done right: you break stuff in the release right after the LTS one, to give people time to adapt.
- krzyk 5y agoIt was just a coincidence. They do it right: ship when it is ready. LTS is not an openjdk term it is something that vendors might offer for any jdk version.
- toyg 5y ago> LTS is not an openjdk term It's an Oracle term, and I expect the majority of OpenJDK committers and decision-makers are still from Oracle.
- carimura 5y agoLTS was proposed by Mark Reinhold [1] who leads the JDK Project in the OpenJDK community in 2017. There was a lot of discussion [2] that resulted in many vendors supporting and adopting the LTS model. It's a thriving ecosystem (which is great!) but yes, Oracle does contribute a significant portion [3]. [1] https://mreinhold.org/blog/forward-faster https://mreinhold.org/blog/forward-faster [2] https://mail.openjdk.java.net/pipermail/discuss/2017-September/subject.html https://mail.openjdk.java.net/pipermail/discuss/2017-Septemb... [3] https://inside.java/2022/03/22/the-arrival-of-java18/ https://inside.java/2022/03/22/the-arrival-of-java18/
- krzyk 5y agoYeah, but OpenJDK commiters thankfully don't care about it. 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).
- ageonel 5y agoOracle is proactively suggesting to test such changes in advance, ex. https://inside.java/2021/12/10/quality-heads-up/ https://inside.java/2021/12/10/quality-heads-up/
- signal11 5y agoWorth noting that if you can, don’t stay on LTS. It adds cost which many modern teams can avoid[1]. 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_project_loom_with_ron_pressler/h1zxsom/?context=3 https://www.reddit.com/r/java/comments/o0m6g8/the_state_of_p...
- throw0101a 5y agoYes, newer JDKs should ideally be rolled into at least DEV and perhaps QA just so breakage can be found early and fixed early. STG/PRD of course is something else. 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.
- danudey 5y agoThis discussion immediately brings to mind all of the iOS apps that become completely unusable the day a major iOS update is released, and then take a week to fix. 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.