3 ms·

Its interesting to compare the general reluctance of the Java community to upgrading vs the Go community's preference to be on the latest version (or at most N-

Its interesting to compare the general reluctance of the Java community to upgrading vs the Go community's preference to be on the latest version (or at most N-1). I suspect this is due to a number of reasons. Go doesn't have a separate runtime component so an upgrade is simply a recompile. I think Go's 1.x compatibility promise has also helped a lot with people feeling confident in upgrading. The Go team tries very hard not to break any existing programs with any of their changes through all 1.x releases. My take away from this is if you are building a platform, don't underestimate the value of stability across upgrades. If upgrades are painless your users won't mind upgrading. If upgrades are a big ordeal, your user will put off upgrading until there is no other possible option.

adambatkin 6y ago
I think there are two reasons why people haven't moved beyond Java 8: 1) There is nothing really compelling (despite what the article says, the performance improvements aren't that important for many real-world applications) 2) For this particular upgrade (anything beyond 8) the Java modularization introduces a pain for some libraries. I suspect that 9->10->11->...16 is totally painless, but 8->9 introduces a little bump.
- cesarb 6y ago
  There's another important bump in 10->11 which removed all of the bundled J2EE, so you have to add external copies of the removed libraries (if they exist; for instance, IIRC the CORBA stuff was removed without an external alternative). In my experience, these external copies have small subtle differences to the former bundled copy, which can cause some issues; though the biggest issue IMO is to find the correct external library name and version for each bundled J2EE library you depended on (and sometimes even which J2EE libraries you depended on, some things are loaded through reflection so it only fails at runtime).
- psanford 6y ago
  People were really bad about upgrading off of Java 6. That was pretty terrible if you operated a TLS endpoint and wanted to drop old insecure configuration options. Sorry, you've got some ancient Java 6 clients that only supports DH 1024. And sadly the security issue is an externality to the owner of the client code. So unless you threaten to cut off their access they don't have much motivation to upgrade.

adambatkin 6y ago

I think there are two reasons why people haven't moved beyond Java 8: 1) There is nothing really compelling (despite what the article says, the performance improvements aren't that important for many real-world applications) 2) For this particular upgrade (anything beyond 8) the Java modularization introduces a pain for some libraries. I suspect that 9->10->11->...16 is totally painless, but 8->9 introduces a little bump.

cesarb 6y ago
There's another important bump in 10->11 which removed all of the bundled J2EE, so you have to add external copies of the removed libraries (if they exist; for instance, IIRC the CORBA stuff was removed without an external alternative). In my experience, these external copies have small subtle differences to the former bundled copy, which can cause some issues; though the biggest issue IMO is to find the correct external library name and version for each bundled J2EE library you depended on (and sometimes even which J2EE libraries you depended on, some things are loaded through reflection so it only fails at runtime).
psanford 6y ago
People were really bad about upgrading off of Java 6. That was pretty terrible if you operated a TLS endpoint and wanted to drop old insecure configuration options. Sorry, you've got some ancient Java 6 clients that only supports DH 1024. And sadly the security issue is an externality to the owner of the client code. So unless you threaten to cut off their access they don't have much motivation to upgrade.