Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Many organizations are stuck on Java 8 because Java 9 made breaking changes. (Java 11 also made breaking changes.) Many of these changes also broke some popular libraries at the time that hacked into the JDK internals, so it meant a significant refactor for software that might be in maintenance mode already.


To clarify Java made changes to things they never promised would be a part of backward compatibility. Libraries were using things from JDK internals/implementation details, things that were never guaranteed to be there.


Is this analogous to the Python 2 to 3 jump?


It isn't that severe of a break. Most of the friction was with the libraries with transitive dependencies, like ASM, that depend on a particular bytecode version, using internal classes that were removed (e.g. sun.misc.BASE64Encoder), or the new module system encapsulating APIs that were intended to be internal-only (usually fixable with JVM runtime flags.)

A lot of organizations that use Java are very conservative with their tech changes, and didn't see a compelling reason to upgrade. This was especially true since Android Java still used Java 8, so many popular libraries continued to support Java 8 for their Android userbase.


No. Java 22 will happily execute code built for Java 6.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: