6 ms·

/me nervously glances at all the production infrastructure I manage that's still on JDK 7 or 8. I've just recently been able to upgrade some things to JDK 11.

watt 6y ago
Not to worry: next LTS release will be Java 17, scheduled for September 2021 - next year.
- krzyk 6y ago
  And you know that LTS in case of Java is meaningless if you don't have a support bundle bought for real money? The only free of charge LTS is the latest java version, all versions n-1, n-2 are out of free support, you can only buy one.
elric 6y ago
JDK 11 is the current LTS version, so that's probably fine. With 2 releases per year, it's hard to follow the bleeding edge. Especially if you have to ship stuff to clients.
- Freak_NL 6y ago
  Yeah, this seems to be par for the field. Java 11 is what you should be targetting now. We're in the middle of the 8 to 11 migration as well. I got the impression (but please correct me if I'm wrong) that only this year most major libraries got all the kinks worked out for Java 11. In particular, when using them together. Guice is one that only recently got the nasty (but relatively harmless) warning you get when using it with Java 11 under control. Java 17 is the next long term support release, so most of us working on longer lived code bases will probably skip all the releases in between. It doesn't seem worth the effort, because if the Java 9 and 10 experience is anything to go by, you will be hunting down issues with Maven plugins, transitive dependencies, and libraries holding back for now all day.
  - vips7L 6y ago
    > Guice is one that only recently got the nasty (but relatively harmless) warning you get when using it with Java 11 under control. Personally I've dropped guice and just stick to Weld anymore since it's the reference implementation of the standard. I haven't had any problems running it on JDK 14.
  - krzyk 6y ago
    > [...] if the Java 9 and 10 experience is anything to go by, you will be hunting down issues with Maven plugins, transitive dependencies, and libraries holding back for now all day. You had issues with 10? The only issues I got were with Java 9, because introduction of modules broke some stuff. Later it was just making sure that ASM or aspectj/lombok is in the most recent version that has new JDK version added, which might have been a problem in 10 (I know I was trying to upgrade on day 1). But nowadays, all the most popular libraries are on par with the next Java version that is in the works at least a month before the release. Since JDK 12, I just do an upgrade every 6 months and had no issues so far. And if you don't ship software to clients then there is almost no downsides to upgrading and a lot of upsides. If you do ship software to clients you should be using jlink, this way you ship smaller binaries and clients don't need to worry about JDK, because you will provide it to them . And you also need to lookup what LTS means in case of Java - it is not the same as in e.g. Ubuntu. In Ubuntu you get free of charge fixes in LTS, in Java you need to buy an LTS version from someone (they will make fixes there) OR use the latest JDK version (which gets all the fixes free of charge).
- pron 6y ago
  It's not hard because the changes are small and gradual, and you have to update your JDK every quarter anyway -- whether you use the current version or an old one -- just to get the security patches. It's just a matter of how that work is spread. It's likely that updating once every 3 years is more work overall. Plus, you've done that already back when there were still major releases, and the semi-annual feature releases didn't get a new integer number (8u20, 8u40 etc. were big feature releases). Plus, keep in mind that LTS is a paid service. What appears to be "free LTS" isn't really LTS, but builds of the OpenJDK Updates projects. Those builds serve as the basis for various paid LTS offerings, but in themselves they don't actually maintain the full JDK. OpenJDK Updates just backports stuff from the mainline version. If you're using a component that's been removed from the mainline -- and you probably do or else you'd upgrade -- then that component is not maintained in OpenJDK Updates (so-called "free LTS") because there's nothing to backport from. The only version that's 100% maintained for free is the current JDK (15 as of today).
  - Yeroc 6y ago
    That's not true unless you mean "free LTS" JDK from Oracle. There are several other projects providing free LTS, TCK-certified builds including: RedHat OpenJDK & Amazon Corretto to name two off the top of my head.
    - pron 6y ago
      No one offers free LTS (or, rather, what you call "free LTS" is very different from a real LTS service, which is always paid, and you might not be getting what you think you are). The "LTS release" you get for free are builds of OpenJDK Updates. Try to open an issue on, say, Nashorn against a "free" LTS 11 and see if it gets addressed. It won't be -- unless you actually pay for a real LTS -- because Nashorn has been removed from the mainline and there's nothing to backport. Same for CMS or any other package or component that's been removed. If you're using one of those "free LTS" distributions you should know that you're using a JDK that's not fully maintained. The only JDK version that's fully maintained completely free is the current version. To be fully safe and run maintained software you can either use the current version for free or use an old version and pay someone for LTS. Maintaining a JDK is a lot of work. There are a couple of hundred full-time developers working on OpenJDK tip and maintaining the current release; there are ~10 full-time engineers (probably less) from all companies combined maintaining both OpenJDK 8u and 11u. For real support for an old version you must pay. (I work on OpenJDK at Oracle)
techdevangelist 6y ago
Lucky! We still have a mix of 1.6, 1.7, and 1.8; our recent big upgrade came from moving a few apps from 1.6 to 1.8... we’ll get to this jdk in about 15 years.
skrebbel 6y ago
I'm clearly missing something, but why is this so hard? I thought Java made a point of being fully backward compatible, both at the source level and the binary level (.class/.jar)? Is that true? If so, why is upgrading to a later jdk more work than, well, installing the newer version?
- Marazan 6y ago
  How Java counts CPUs in a Docker like world has changed multiple times since JDK8. That might not sound too important but it has an effect on GC chosen amd obviously how you might have tuned your thread pools.
- sgift 6y ago
  Between JDK8 and 9 there was the introduction of the module system, which broke many systems, cause they did somethings they weren't allowed to do in the first place (and which wasn't included in the backwards compatibility guarantees): Access internal JDK classes. There were some compromises to make it still work (e.g. they continued to allow access to some parts of sun.misc.unsafe until there's a replacement with the same performance, cause most of the things in there are pretty fast), but some things just didn't work with the module system and had to be changed. By now, I'd say if you depend on a library that still doesn't work on JDK9+ you should replace it, but depending on your requirements that may not be so easy and so some people are still stuck on JDK8.
- Semaphor 6y ago
  There are at least some versions that aren’t binary compatible. Because of that we have one system stuck on JDK 7 :/
- tandr 6y ago
  (not gp) It is about stability, and that magical ephemeral "Something". In software, like JDK or OS, "Something" does change all the time with bug fixes and maybe even just a different builds. Jump from 8 to 11 has a lot of Somethings changed, and transition is not always painless. I have tests that use JSON serialization and deserialization (and then some), and they pass perfectly fine on Java 8 runtime, but fail in exactly same place on Java 11, without recompilation. I have spent some non-zero time trying to get to the bottom, but so far without much luck.
krzyk 6y ago
The things you migrated to JDK 11, can be easily migrated to JDK 15 (or at least 14, if you have some libs depending on Nashorn), the biggest issue with migration was JDK 9 (because of the modules), so if you are past that then it is a breeze.

watt 6y ago

Not to worry: next LTS release will be Java 17, scheduled for September 2021 - next year.

krzyk 6y ago
And you know that LTS in case of Java is meaningless if you don't have a support bundle bought for real money? The only free of charge LTS is the latest java version, all versions n-1, n-2 are out of free support, you can only buy one.

elric 6y ago

JDK 11 is the current LTS version, so that's probably fine. With 2 releases per year, it's hard to follow the bleeding edge. Especially if you have to ship stuff to clients.

Freak_NL 6y ago
Yeah, this seems to be par for the field. Java 11 is what you should be targetting now. We're in the middle of the 8 to 11 migration as well. I got the impression (but please correct me if I'm wrong) that only this year most major libraries got all the kinks worked out for Java 11. In particular, when using them together. Guice is one that only recently got the nasty (but relatively harmless) warning you get when using it with Java 11 under control. Java 17 is the next long term support release, so most of us working on longer lived code bases will probably skip all the releases in between. It doesn't seem worth the effort, because if the Java 9 and 10 experience is anything to go by, you will be hunting down issues with Maven plugins, transitive dependencies, and libraries holding back for now all day.
- vips7L 6y ago
  > Guice is one that only recently got the nasty (but relatively harmless) warning you get when using it with Java 11 under control. Personally I've dropped guice and just stick to Weld anymore since it's the reference implementation of the standard. I haven't had any problems running it on JDK 14.
- krzyk 6y ago
  > [...] if the Java 9 and 10 experience is anything to go by, you will be hunting down issues with Maven plugins, transitive dependencies, and libraries holding back for now all day. You had issues with 10? The only issues I got were with Java 9, because introduction of modules broke some stuff. Later it was just making sure that ASM or aspectj/lombok is in the most recent version that has new JDK version added, which might have been a problem in 10 (I know I was trying to upgrade on day 1). But nowadays, all the most popular libraries are on par with the next Java version that is in the works at least a month before the release. Since JDK 12, I just do an upgrade every 6 months and had no issues so far. And if you don't ship software to clients then there is almost no downsides to upgrading and a lot of upsides. If you do ship software to clients you should be using jlink, this way you ship smaller binaries and clients don't need to worry about JDK, because you will provide it to them . And you also need to lookup what LTS means in case of Java - it is not the same as in e.g. Ubuntu. In Ubuntu you get free of charge fixes in LTS, in Java you need to buy an LTS version from someone (they will make fixes there) OR use the latest JDK version (which gets all the fixes free of charge).
pron 6y ago
It's not hard because the changes are small and gradual, and you have to update your JDK every quarter anyway -- whether you use the current version or an old one -- just to get the security patches. It's just a matter of how that work is spread. It's likely that updating once every 3 years is more work overall. Plus, you've done that already back when there were still major releases, and the semi-annual feature releases didn't get a new integer number (8u20, 8u40 etc. were big feature releases). Plus, keep in mind that LTS is a paid service. What appears to be "free LTS" isn't really LTS, but builds of the OpenJDK Updates projects. Those builds serve as the basis for various paid LTS offerings, but in themselves they don't actually maintain the full JDK. OpenJDK Updates just backports stuff from the mainline version. If you're using a component that's been removed from the mainline -- and you probably do or else you'd upgrade -- then that component is not maintained in OpenJDK Updates (so-called "free LTS") because there's nothing to backport from. The only version that's 100% maintained for free is the current JDK (15 as of today).
- Yeroc 6y ago
  That's not true unless you mean "free LTS" JDK from Oracle. There are several other projects providing free LTS, TCK-certified builds including: RedHat OpenJDK & Amazon Corretto to name two off the top of my head.
  - pron 6y ago
    No one offers free LTS (or, rather, what you call "free LTS" is very different from a real LTS service, which is always paid, and you might not be getting what you think you are). The "LTS release" you get for free are builds of OpenJDK Updates. Try to open an issue on, say, Nashorn against a "free" LTS 11 and see if it gets addressed. It won't be -- unless you actually pay for a real LTS -- because Nashorn has been removed from the mainline and there's nothing to backport. Same for CMS or any other package or component that's been removed. If you're using one of those "free LTS" distributions you should know that you're using a JDK that's not fully maintained. The only JDK version that's fully maintained completely free is the current version. To be fully safe and run maintained software you can either use the current version for free or use an old version and pay someone for LTS. Maintaining a JDK is a lot of work. There are a couple of hundred full-time developers working on OpenJDK tip and maintaining the current release; there are ~10 full-time engineers (probably less) from all companies combined maintaining both OpenJDK 8u and 11u. For real support for an old version you must pay. (I work on OpenJDK at Oracle)

techdevangelist 6y ago

Lucky! We still have a mix of 1.6, 1.7, and 1.8; our recent big upgrade came from moving a few apps from 1.6 to 1.8... we’ll get to this jdk in about 15 years.

skrebbel 6y ago

I'm clearly missing something, but why is this so hard? I thought Java made a point of being fully backward compatible, both at the source level and the binary level (.class/.jar)? Is that true? If so, why is upgrading to a later jdk more work than, well, installing the newer version?

Marazan 6y ago
How Java counts CPUs in a Docker like world has changed multiple times since JDK8. That might not sound too important but it has an effect on GC chosen amd obviously how you might have tuned your thread pools.
sgift 6y ago
Between JDK8 and 9 there was the introduction of the module system, which broke many systems, cause they did somethings they weren't allowed to do in the first place (and which wasn't included in the backwards compatibility guarantees): Access internal JDK classes. There were some compromises to make it still work (e.g. they continued to allow access to some parts of sun.misc.unsafe until there's a replacement with the same performance, cause most of the things in there are pretty fast), but some things just didn't work with the module system and had to be changed. By now, I'd say if you depend on a library that still doesn't work on JDK9+ you should replace it, but depending on your requirements that may not be so easy and so some people are still stuck on JDK8.
Semaphor 6y ago
There are at least some versions that aren’t binary compatible. Because of that we have one system stuck on JDK 7 :/
tandr 6y ago
(not gp) It is about stability, and that magical ephemeral "Something". In software, like JDK or OS, "Something" does change all the time with bug fixes and maybe even just a different builds. Jump from 8 to 11 has a lot of Somethings changed, and transition is not always painless. I have tests that use JSON serialization and deserialization (and then some), and they pass perfectly fine on Java 8 runtime, but fail in exactly same place on Java 11, without recompilation. I have spent some non-zero time trying to get to the bottom, but so far without much luck.

krzyk 6y ago

The things you migrated to JDK 11, can be easily migrated to JDK 15 (or at least 14, if you have some libs depending on Nashorn), the biggest issue with migration was JDK 9 (because of the modules), so if you are past that then it is a breeze.