Also, there isn't much new code being written for 8, and there's a whole lot more of Java code yet to be written than the non-portable code still on 8. In fact, even most existing projects are no longer on 8. Sure, if you only look at the pain, there has certainly been some. But if you look at the pain compared to the benefit, the lesson is that it's been a great success, especially compared to other languages (or even frameworks) doing similar significant changes. I think the vast majority of those who've upgraded consider it worthwhile (again, comparing cost/benefit).
Virtual threads, FFM, and the upcoming Valhalla and Leyden are all things that could not have been done without modularisation, and certainly not without significant internal JDK changes, which would have kept the same people on 8 even if there was some way (doubtful and definitely much more expensive) to achieve that without modularisation. We would have been in a far worse place without it: fewer new features and no end to the problem of migration.
We don't give ETAs as people may make business decisions based on them. As a matter of policy, we only announce a targeted JDK within the 6 months prior to its release.
> it’s getting quite tedious to persuade everyone to keep it up and not jump ship, after getting burned by the previous JDK (and Spring) upgrades.
If nothing else, they should be placated by the fact that upgrades are significantly worse in every other ecosystem.
A lot of ecosystems care about their users and care about compatibility. Java is a toxic relationship at this point.
Yep, that's why we introduced the LTS service. People may not have noticed before we did away with major releases and changed the version naming scheme, but in the past you had no choice but to upgrade to semi-annual releases with major VM changes, like 8u20 or 7u4 (probably because the name was too similar to patch releases, like 8u30 or 7u5). Now, with LTS, we try to only backport security patches and major bug fixes to make sure that such legacy users get the stability they need.
It's an obsession over "pure" code that has no basis in reality. I'm sorry: Applets don't exist anymore, this obsession is outdated and futile. There is no rational justification behind breaking compatibility with almost every large Java project in existence to the extent that https://java.com still downloads Java 8.
No. JDK 9 and 11 kept all default accessibility the same as in JDK 8 (all you got was a warning) until it was changed in JDK 16: https://openjdk.org/jeps/396
The adoption issues were almost entirely due to non-portable libraries depending on internal implementation details that had changed in 9. Some were due to changes like that to the version string that dropped the "1." prefix for the first time.
> It's an obsession over "pure" code that has no basis in reality. I'm sorry: Applets don't exist anymore, this obsession is outdated and futile.
I don't understand the relationship to Applets, but the emphasis on integrity (a generalisation of safety) is all around the software world. It's the main reason for Rust's existence.
> to the extent that https://java.com still downloads Java 8.
That's because java.com is a website for end users downloading the JRE, which was discontinued after 8 (really in 11).
This is simply not true. This sounds like gaslighting in an attempt to rewrite history, which IMHO shows poor credibility from the JDK developers.
> I don't understand the relationship to Applets, but the emphasis on integrity (a generalisation of safety) is all around the software world. It's the main reason for Rust's existence.
Yes, and Rust has "unsafe". Java still has JNI. If programmers want to write unsafe code, they will write it, to the point of shipping a modified JVM. It's their computers. It's their code. It is a misguided and fruitless effort to push ideology on them.
> That's because java.com is a website for end users downloading the JRE, which was discontinued after 8 (really in 11).
I don't buy this.
I'm sorry, but default access was not changed until JDK 16. Here's the relevant section from JDK 9's JEP 261 (https://openjdk.org/jeps/261#Relaxed-strong-encapsulation):
In this release the strong encapsulation of some of the JDK's packages is relaxed by default... --illegal-access=permit opens each package in each module in the run-time image to code in all unnamed modules, i.e., to code on the class path, if that package existed in JDK 8. This enables both static access, i.e., by compiled bytecode, and deep reflective access, via the platform's various reflection APIs... This mode is the default in JDK 9.
> Yes, and Rust has "unsafe". Java still has JNI. If programmers want to write unsafe code, they will write it, to the point of shipping a modified JVM. It's their computers. It's their code. It is a misguided and fruitless effort to push ideology on them.
And Java will still gives you access to unsafe operations (even after this change) albeit with a flag that serves a similar purpose to Rust's unsafe, only done better. The goal is not to impose an ideology on programmers. If you read the JEP, the goal is for them, and the runtime, to know which invariants can be trusted and which can't (e.g. the JIT might want to optimise things based on the assumption that strings are final, but using unsafe code or native code makes that untrue). That's why JNI will also require a flag. As it is today, neither the runtime nor the application developer is able to know whether there's some code that could mess about with their assumptions.
> I don't buy this.
It literally says that on the front page of java.com: "Get Java for desktop applications." OTOH, the developer website, https://dev.java/, lets developers download JDKs only, as JREs no longer exist.
Two months ago I did a fresh deploy of Java 8 in production for a SaaS solution, exactly because that is what the product and support team care about.