Java 8 → Java 11 → Java 17. Those are the LTS releases. If you want to follow a release cadence similar to Java 5 → Java 6 → Java 7 → Java 8, that's what you'll track.
The intermediate releases can be used to test against, but adopting them too soon often means tackling lots of issues in your dependencies. And updating your application servers to a new major Java version every six months is not something you can do easily coming from older Java versions. It's not impossible, but it may require a different deployment strategy and may not benefit you much over going from LTS to LTS.
I think that there is also an unspoken feeling that the LTS releases are more stable, which again may be due to the libraries you depend on not always being as well tested on the intermediate releases. I think a lot of Java developers burned their fingers on Java 9 and 10 and are now sticking to the LTS releases, but that is just my gut-feeling.
I struggle to imagine any meaningful definition for LTS that includes "tracking latest" except by coincidence (during the window of time when the most recent release is an LTS release).
If you're doing green field JVM developer and NOT using big frameworks like Spring or an app server it is pretty safe to use the intermediate releases.
... if you're willing and able to update your entire app to a new JDK the month it comes out.
This is where I hope Java adopts the .NET support lifecycle. .NET also has (relatively) fast-paced releases now, once per year with LTS every other year, but the prior non-LTS is supported for 3 months after the next one comes out. That's still pretty aggressive, but it's very doable with a modern app to upgrade within 3 months.
With Java, JDK 15 support ends this month, the same month that JDK 16 comes out. Not just that, but we're halfway through the month already. So if you're on JDK 15, you now have only two weeks to upgrade and still be supported, according to their official schedule.
Edit: I may have been too generous in my reading of their support roadmap. It seems like the previous non-LTS version is immediately out of support as soon as the new one "supersedes" it.
Uh, probably just my narrow corporate world view but... is there any serious development in java NOT using Spring?
Time for me to learn so let me rephrase this question!
Those who use java without EE or Spring framework, what are your go-to libraries? What are you using for DI / REST / ORM / Auth etc?
> is there any serious development in java NOT using Spring?
Yes. And I don't just mean people doing Android development.
1) DI: Don't always need DI. For things like injecting values from config, it's really unnecessary given that we have very good control over production, down to building our boxes from a playbook. For things like mocks, plain old Java suffices -- you can roll your own (actually, someone in your team just needs to do it once and it keeps getting improved/forked). Guice exists as a fallback.
2) REST: Jersey + own libraries on top, Retrofit. Using Spring for REST is probably the poorest use for Spring, for me.
3) ORM: you can use "just" JPA. Don't always need an ORM either -- the strategy varies depending on the requirement. Although for some projects I have used Spring Data JPA because it seemed like the easiest path. At least Spring was localized to that artifact.
4) Lots of good OAuth2 libraries as well as things like pac4j. If you're wondering about Spring Security, it's definitely one to consider if you're doing lots of webapps in Java. But in a polyglot environment, a lot of Java code just handles APIs while node handles the UI.
Anyhow, this isn't to hate on Spring or anything -- I use it if it adds value. This is more about not taking the the complexity hit if you can help it. It also makes the code a bit more straightforward and readable.
Different needs for different domains. For example, there's an old pack of machine learning code that I maintain, and it (and a bunch of other Java code that I see from other institutions) does not use or need DI, ORM, Auth nor proper REST, they typically handle processing of non-database data with no or minimal web interaction, and plain old objects are fine for that - if we started from scratch and chose Java instead of some other language, we would still not use Spring for that.
Google used Guice for DI (Or Dagger2 sometimes), rest is it's own thing, orm is "there is no ORM go write your spanner queries", and Auth is it's own thing.
Note that blindly following LTS is not a great idea for many teams that deploy applications (as opposed to libraries), including teams working in large companies, if you have access to modern CI/CD tooling. Personally, I'd let production stay a little behind the latest release but always run a task on my build server to build and test my code on the latest JRE.
If you read Ron Pressler's comment on Reddit[1], the recommendation is
> In any event, the default position should be to keep up with the current JDK as much as possible (it's OK to skip a version or two), and consider LTS only if there is some specific difficulty preventing you from doing so. As I said before, the "current JDK" upgrade path is designed to be the one that is overall the cheapest and easiest for the vast majority of users -- easier and cheaper than the old model.
For users who are happy with the current JDK language level, newer releases also have JRE improvements:
> ...those users should [also] prefer the current JDK, too, as that is the easiest, cheapest update path. Also, new feature releases contain performance and monitoring improvements (e.g. JFR, ZGC, AppCDS in the last few releases) that may be of interest even when users are not interested in new language/library features.
> The problem with LTS is that it's costly (costlier than the old model): on the one hand, the risk of a breaking change in an LTS patch is no lower than in a feature release, and on the other hand, the patches no longer contain many gradual implementation features (that you use without knowing). In addition, the OpenJDK development process revolves around feature releases without regard for LTS, so features can be removed without notice in an LTS release. This makes an LTS->LTS upgrade more costly than in the old model.
> LTS is designed and is advisable for companies that prefer a costly, but well-planned, three-yearly upgrade process.
> Even if you've carefully considered the options and decided that LTS is the right approach for you, you are strongly advised to test your app against the current JDK release to reduce the cost of an LTS->LTS upgrade.
> It's true that upgrading from 8 to post-9 can be non-trivial (9 was the last ever major release), but once you do that, you have an update path that ensures you'll not have a major upgrade ever again.
Java upgrades inside enterprises cost time and money, no sense in taking that cost if you can help it, and many engineering teams with good DevOps can easily dodge this cost.
And what do you do if you "try it out" and some months later you identify a problem? Then you have to rewrite all the code without the new features to go back to the LTS version, and likely you'll have to downgrade or even swap out some of your dependencies. That's painful and expensive, there needs to be a very good reason to justify that risk.
You don't need to downgrade dependencies, libs are at 8 and 11 right now and support up to 16 (e.g. jackson is I think at Java 7, and supports records from Java 16).
What kind of problem could you identify? Same might happen with LTS release (e.g. I had it in JDK 8, suddenly I wasn't able to use some crypto libs).
Fixes always go first to JDK latest, and then are backported to 11 and 8.
If you're using JBoss/Wildfly the recommendation is to stick to the LTS. The last JDK supported is 13 since 14 removed some API's and the team is still working to fix it.
The intermediate releases can be used to test against, but adopting them too soon often means tackling lots of issues in your dependencies. And updating your application servers to a new major Java version every six months is not something you can do easily coming from older Java versions. It's not impossible, but it may require a different deployment strategy and may not benefit you much over going from LTS to LTS.
I think that there is also an unspoken feeling that the LTS releases are more stable, which again may be due to the libraries you depend on not always being as well tested on the intermediate releases. I think a lot of Java developers burned their fingers on Java 9 and 10 and are now sticking to the LTS releases, but that is just my gut-feeling.