3 ms·

The safest, cheapest choice for applications that are heavily maintained is to use the most recent version. LTS is designed for legacy applications that are no

by pron 5y ago

The safest, cheapest choice for applications that are heavily maintained is to use the most recent version. LTS is designed for legacy applications that are no longer heavily developed, and might benefit from security and bug fixes only (note that this model is new; in the past, back when there were major versions, minor updates included both patches and big features).

fwip 5y ago
It also depends on your target environment, and how much control you can exert over the machine where your software will run. Sometimes you're creating an app that other users need to run in their own environments - and in that case, targeting "latest LTS" is safer, as they may have requirements on what they can run that you don't.
- pron 5y ago
  True, there are, indeed, times when you can't use the current version, but note that Java applications are now encouraged to bundle their own runtime (generated with jlink).
karmakaze 5y ago
'heavily developed' is the operative consideration as this means upgrading (not merely updating) your Java installations every 6 months.
- pron 5y ago
  With major releases gone, this isn't hard, and, overall cheaper and easier than upgrading less frequently. But it is some work, which is why the LTS service was added for the benefit of legacy applications. Note that under the old model, LTS didn't exist. There was a new feature release every six months that everyone had to upgrade to. The names of those releases didn't stand out as much (8u20, 8u40 for feature releases [1] as opposed to, say, 8u25, 8u45 for patches) as they do now when we did away with major releases and gave every new feature release a new integer number. Because now the feature releases can add new APIs rather than just new JVM features as they did under the old model, this process can be slightly more work, but still significantly less work over time. As regularly maintained applications update code and dependencies regularly, anyway, this is a clear win. Not only is the upgrade process easier and cheaper, but you get to enjoy the regular and significant performance improvements that have always been part of the six-monthly feature releases, but aren't in the LTS patches. [1]: Those feature releases under the old model also added major new features with significant changes to the VM. For example, the G1 GC and JFR were added in feature releases.
- krzyk 5y ago
  Which is quite painless, I do it since JDK 10, upgrade up to 1 week after JDK release and it was painless (with one exception around JDK 12 or 13 where spring have some issue for 1 month until I could upgrade).

by pron 5y ago

fwip 5y ago

It also depends on your target environment, and how much control you can exert over the machine where your software will run. Sometimes you're creating an app that other users need to run in their own environments - and in that case, targeting "latest LTS" is safer, as they may have requirements on what they can run that you don't.

pron 5y ago
True, there are, indeed, times when you can't use the current version, but note that Java applications are now encouraged to bundle their own runtime (generated with jlink).

karmakaze 5y ago

'heavily developed' is the operative consideration as this means upgrading (not merely updating) your Java installations every 6 months.

pron 5y ago
With major releases gone, this isn't hard, and, overall cheaper and easier than upgrading less frequently. But it is some work, which is why the LTS service was added for the benefit of legacy applications. Note that under the old model, LTS didn't exist. There was a new feature release every six months that everyone had to upgrade to. The names of those releases didn't stand out as much (8u20, 8u40 for feature releases [1] as opposed to, say, 8u25, 8u45 for patches) as they do now when we did away with major releases and gave every new feature release a new integer number. Because now the feature releases can add new APIs rather than just new JVM features as they did under the old model, this process can be slightly more work, but still significantly less work over time. As regularly maintained applications update code and dependencies regularly, anyway, this is a clear win. Not only is the upgrade process easier and cheaper, but you get to enjoy the regular and significant performance improvements that have always been part of the six-monthly feature releases, but aren't in the LTS patches. [1]: Those feature releases under the old model also added major new features with significant changes to the VM. For example, the G1 GC and JFR were added in feature releases.
krzyk 5y ago
Which is quite painless, I do it since JDK 10, upgrade up to 1 week after JDK release and it was painless (with one exception around JDK 12 or 13 where spring have some issue for 1 month until I could upgrade).