Re:Java 22 Released
by fngjdflmdflg on Tuesday March 19, 2024 @05:03PM
(#39760192)
Wasn't the whole point of Java never releasing a 2.0 that there would never be breaking changes? Seems like something went very very wrong with Java if the state they are in is that the language refuses to make breaking changes and the developers refuse to take up the supposedly non breaking updates due to breaking changes based on the comments I'm seeing here. So the language never improves as much as it can and the developers never update anyway making the whole point of non-breaking changes moot.
[ Parent
| on HN ]
Java 8 allows access to unsafe methods, which despite being meant for internal JDK use only, have been widely used in external projects. Newer Java versions do not permit the use of unsafe except for the JDK itself.
It wasn't ever part of the public API that's promised to never break, and JDK developers were annoyed that it being used meant Java got perceived as unstable, and it's gone in more recent versions.
I thought the issue was not Unsafe methods (which are only just now starting to be marked for removal) but rather various bytecode weaving libraries like javassist. As the JDKs progressively enforce bytecode verification more strictly these libraries sometimes run afoul of the new restrictions. (I speak from a little experience here, managed a somewhat involved upgrade path from 7 to 8 way back in the day which had this issue.)
That's probably another factor, and these two aren't the only ones.
I haven’t ever seen this mentioned. The real culprit was libraries that go into jdk internals when they shouldn’t have so end user applications couldn’t upgrade until those libraries upgraded.
Re:Java 22 Released
by marginalia_nu on Tuesday March 19, 2024 @10:32PM
(#39762396)
Huh, but I'm using Unsafe in JDK 21?
There are barely any breaking changes, I could still run a graphical application written by a prof in early 2000s, served on his website as a jar. No other language comes remotely as close to this level of stability.
As for the changes in 8->9, there was a stagnation period in the last year of Sun, and many people overfitted their libs to 8, by e.g. making use of internal APIs made accessible through reflection. This was never a good idea, and all that is happening now is that you have to explicitly state at invocation what kinds of non-future-proof modules you make use of, so that you are made aware of what could potentially change, plus it disincentivizes libraries from accessing these non-public APIs.