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.
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.
[1] https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i... , https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i...