3 ms·

Most Java projects written for JDK 1.2 still run fine, unchanged and without recompilation, on JDK 22, provided that they don't make use of libraries that bypas

by pron 3y ago

Most Java projects written for JDK 1.2 still run fine, unchanged and without recompilation, on JDK 22, provided that they don't make use of libraries that bypass the spec and reach for internals (or unless they're using discontinued technologies like Applets, although those would still be easy to port). Java's backward compatibility only applies to the spec, not to internal implementation details. Before internals were encapsulated in JDK 16, too many libraries reached for internals, and these non-portable libraries made their client applications non-portable without their knowledge. Those libraries reached for internals to add functionality and to improve performance, but in the process knowingly sacrificed portability but didn't make that tradeoff apparent to consumers. Now that internals are encapsulated, upgrades are easier than they've ever been at any point in Java's history. Unfortunately, some large applications that depend on non-portable libraries — some of which were since abandoned — are stuck, but support for JDK 8 continues at lest until 2030.

jmaker 3y ago
Thanks for these insights, Ron. Indeed, it’s mostly due to the dependencies that it’s not always simple to upgrade. Some Gradle plugins must also be updated. Code generators are rather fragile and some of them bluntly violate javac constraints but have been pulled as dependencies rather widely nonetheless. Yes, from the JDK vendor perspective on backwards compatibility and lifecycle support extensions, OpenJDK’s and Oracle’s track record is stellar, that's been my honest opinion throughout. Beyond JDK though, the community has been trying to move forward in ways inconsistent with the backward compatibility for projects with dependencies such as those that you describe. This is what's causing most of the hesitation, exacerbated by the modality that there's little clarity on how to replace or upgrade such shenanigans. From your comments, it turns out I’m quite unaware of the details of the transition to the encapsulation of the internals. I recall you mentioning that some time ago too. I’d appreciate a pointer to some overview, I feel like I’m going to need one before making a dive into the rabbit hole.
- pron 3y ago
  https://openjdk.org/jeps/8305968 https://openjdk.org/jeps/8305968

by pron 3y ago

jmaker 3y ago

Thanks for these insights, Ron. Indeed, it’s mostly due to the dependencies that it’s not always simple to upgrade. Some Gradle plugins must also be updated. Code generators are rather fragile and some of them bluntly violate javac constraints but have been pulled as dependencies rather widely nonetheless. Yes, from the JDK vendor perspective on backwards compatibility and lifecycle support extensions, OpenJDK’s and Oracle’s track record is stellar, that's been my honest opinion throughout. Beyond JDK though, the community has been trying to move forward in ways inconsistent with the backward compatibility for projects with dependencies such as those that you describe. This is what's causing most of the hesitation, exacerbated by the modality that there's little clarity on how to replace or upgrade such shenanigans. From your comments, it turns out I’m quite unaware of the details of the transition to the encapsulation of the internals. I recall you mentioning that some time ago too. I’d appreciate a pointer to some overview, I feel like I’m going to need one before making a dive into the rabbit hole.

pron 3y ago
https://openjdk.org/jeps/8305968 https://openjdk.org/jeps/8305968