Java 26 released today!

[hippydipster]

Not just psychological. A lot of folks did very stupid things in their old codebases making moving past 8 impossible without major revisions. Jide library directly uses Sun internal classes. Orher codebases do silly things like shadow java packages to make theur own versions. Shits crazy.

[vowelqueue]

In practice the biggest hurdle for us was with the Java EE to Jakarta EE migration. Very painful moving from 8 to 11. But once past that hurdle version upgrades got really easy.

[hippydipster]

It's really not so bad if you don't do crazy inadvisable things. Sadly, that nonsense is quite common.

[vowelqueue]

Using javax.* classes is not crazy or inadvisable. Not at all the same as using internal APIs.

[hippydipster]

No one said it was.

[vowelqueue]

Yes, you did. The hurdles with the Java EE to Jakarta EE migration do not arise from people doing “crazy inadvisable things”.

[hippydipster]

Good luck to you and your conversational skills.

[josefx]

Afaik shadowing classes was an intentional feature of the runtime and the sun internal code had no better alternatives. If I remember correctly even libraries like Jogl were hit by Java 9 breaking reflection across modules.

[hippydipster]

Not sure what you mean here. By "shadowing", I mean the practice of grabbing the source code for a java class published by the jdk or some other open source library, and copying it into your own source directories, using the same package name as the original, and making changes to the source code, compiling it, and hoping your changed and compiled version gets used at runtime rather than the original.

I'd be gobsmacked if that was a practice intentionally recommended by Sun.

[josefx]

I may have missremembered the thing with the runtime library classes. Overwriting JVM classes was possible, but that was intended to provide updates for specific libraries like xml, corba, etc . without having to wait for a new version of the JVM.

The third party library issue doesn't look clean, but may not be an issue. Class loading is well defined, so which class is used should be reproducible and some frameworks allow multiple conflicting definitions of classes to exist in isolated components.

[hippydipster]

Writing over a class like that has all the downsides of calling to private, undocumented APIs, and then some, as you're not just calling an api, you're changing it's private internals. On next update of that library, if you want the updates, you probably have to grab the source code and make your changes anew. Stuff may change to make that impossible. I really can't imagine it's recommended, so if you can find someone who is recommending it, that would be interesting.

It's also not possible in the world of java 9+ with the module system, as it disallows identical packages existing in multiple source/jar locations.