2 ms·

Of course, a classical trade-off. That’s why I’m taking time to discuss that here. The cost incurred by upstream updates reshuffling the hull makes it for hard

by jmaker 3y ago

Of course, a classical trade-off. That’s why I’m taking time to discuss that here. The cost incurred by upstream updates reshuffling the hull makes it for hard budget and timeline decisions and risk management. That’s why larger projects with many deps prefer stable upstream, both the runtime and the libs. There’s also compliance and certification that come into play in regulated industries. Lots of moving parts to keep track of. I need to know what the upstream vendors are up to so we can plan in advance. With JDK, a big trouble is the push to JDK 17+ now within the ecosystem. Sonar Cloud for example now wants JDK 17+ starting next Monday. But you can’t even build your JDK 11 bound projects with Gradle that runs on JDK 17. You could separate the build stage from the run stage, of course, but that’s not really enough in the end. Same story with Spring. With .NET by contrast, the ecosystem still supports the legacy .NET Framework target and you can still run your antiquated projects. Not the same with Java anymore though. It’s pulling the rug.

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 jmaker 3y ago

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