> If you want security/bug fixes, you'll need to upgrade your application to the new JDK every 6 months. For a team like ours (~8) people, it's simply not viable for us to be in a state of continual upgrading.

You need to upgrade to a new JDK every couple of months if you want to stay secure even if you stay on LTS. You are simply assuming that upgrading to patches is easier than upgrading to feature releases. I don't believe this is true, certainly not over a long duration.

The new feature releases are time-based and were originally meant to be called 18.3, 18.9, 19.3 etc. Don't be confused by the fact that eventually people preferred the Chrome-like version naming scheme to mean that the new feature releases are major ones; they are not. In fact, the probability that your application would break by a patch release and by a feature release is not all that different.

We want the feature release process to be gradual and cheapest overall. The LTS path is meant for those who for some reason need a less gradual process than either the feature releases or the old model.

Of course, as an Oracle employee, I value your business, and I hope you choose to buy our support (that includes more than patches) even if you switch to the gradual update process.

Ideally if I had any say in the matter, I'd also choose to continue the upgrades. I'm unfortunately not in a position to be able to make decisions for the company, or even team really.

The culture for us leads to more problems imo. Tests aren't required. We have > 100 legacy applications (most C#, but some java). I'm currently working on porting a webapp developed 5 years ago, written on jdk6 (I think) using Hibernate 4.x.y, to java 11. There's no tests for the webapp. The majority of the code was written by contractors. I've removed hundreds (if not 1-2 thousand) of lines of commented out or dead code before I even started refactoring. In this case, which I agree is probably an outlier, updating takes too long. Or maybe I'm too inexperienced.

In my managers eyes, they see how long it's taking to migrate to JDK 11, and they don't want that for every new "major release" (12, 13, etc)

> In my managers eyes, they see how long it's taking to migrate to JDK 11, and they don't want that for every new "major release"

How long to manage from what version? There was one huge major version between 8 and 11 -- 9, the last one ever. So if you go from 8 to 11, then you're basically doing one major release, plus two feature ones.

> Tests aren't required.

That's unfortunate, because even patch releases can break your application (and possibly at a probability that's not significantly lower than that for a feature release, although they are both low). In fact, this happened in 11.0.2/8u201[1], which was possibly more disruptive than any of the recent feature releases. Both feature and patch releases require the same amount of testing on update. If someone thinks they don't, then they are very deeply misguided.

Getting support is good, but having an understanding of the platform is also good. Having good tests is probably better than both :)

[1]: https://www.reddit.com/r/java/comments/ba79hh/beware_of_comp...

So I have been in Java versioning hell before, and I empathize--but that was, like, Java 5 to 6. My experiences with Java since then have been almost completely seamless. So, this may be a silly question, but I'd be curious: what is so disruptive to your workflow that upgrading a JDK, running your test suite under instrumentation to smoke out incompatibilities and noticeable perf/memory/etc. regressions, and deploying it would cause you to not "get anything else accomplished"?

I can't speak for the OP, but from what I've seen in other organizations a reluctance to upgrade JDK versions usually indicates a lack of confidence in their test automation suite. If they can't be confident that their tests will catch regression defects then a JDK upgrade seems risky and requires planning ahead for a major manual testing effort. This is just one area where getting to 100% automated functional testing delivers huge benefits.

Pretty much right on the nose. As I mentioned elsewhere, testing is not required where I work. As such, there's no guarantee that upgrades to JDK won't break something behind the scenes now only to blow up later in production.

Most test suites cannot test long-term stability. We once had a commercial J2EE app that would run fine for weeks on JDK 7.x but commit continual-GC suicide or burn 100% of all cores after about 24 hours on JDK 7.x+1.

After this happened with multiple oracle “bug fix” releases, we of course stopped upgrading as much as possible, spending days trying to determine if each security hole being patched in the JDK was actually an attack vector for this app.

We also implemented periodic “therapeutic restarts” on all app servers.

It was like running a critical server app on Windows 95.

Major java versions have been known to have different default settings/properties from previous versions, without any mention whatsoever in the release notes.

Any 'minor' change in a user application, font being a common example, can have a significant negative impact for an enterprise that has built workflows around that application.

That assumes we have (any) tests, or benchmarks to refer to. Plus, we have a decent amount of legacy java apps (java 6 - 7) and we'd be going straight to 11. On the project I'm on now, it's not a smooth transition.

I mean, yes, it does. But at that point...maybe you need it? :-/

(I know, politics. But also, sustainability.)

Care to post what stack you’re on? We’re on Gradle and SpringBoot and JDK upgrades have been zero changes for us so far (other than changing the version number of course). The backwards compatibility has been superb - what breaks for you?

Not the OP, and our stacks/reasons are probably different, but for perspective, I work on a large Canadian Federal Government project, and a minor change in Java version on severs for our legacy application, is probably... 1-2 months elapsed time, minimum. And that's if we get the change approved. Mostly it's the slow and manual change management practices, slow and manual approval framework, slow and manual testing approach, slow and manual implementation procedures, and other things that are slow and manual.

Maven, Hibernate, Jersey, Jettison/Jackson. All developed on Java 7 I believe, so the jump is rather large.

That's true of all other languages though. Go, Ruby, etc. don't offer backported releases as well.

Also, you can use the community packages, such as AdoptOpenJdk, which will offer backported fixes on old releases for a much longer period.

And then there is Amazon Coretto, which is free.

As well as Azul or RedHat, but those are mostly paid as well.