[thewisenerd]

recently pulled the trigger on a migration out of jdk8

we decided to bite the bullet and do 21 instead of 17; one of the reasons being 25 being just around the corner.

as far as i can tell, the biggest hurdle is 8 to 11 (with the new modules system); but it's smooth sailing from there. the proof-of-concept was done with jdk17, but it worked as-is with jdk21 (except guice which needed a major version bump).

(of course being with a jvm language instead of java itself also probably helped)

[MBCook]

For us 8 to 17 was tough due to a lot of things you weren’t supposed to be using going away (sun packages). But TONS of libraries did it anyway. And the move from javax to jakarta for a lot of things in there was also tough.

If you could get through that, you’re golden. From what I’ve seen going to 21 or 25 look easy. They’re just adding features, the big upheavals of doing the long needed cleanup are over.

I expect keeping up to date to be far easier from now on.

[cesarb]

> For us 8 to 17 was tough due to a lot of things you weren’t supposed to be using going away (sun packages). But TONS of libraries did it anyway.

AFAIK, these libraries did so because there was no alternative, and some of the changes in Java 9 and later were done to provide them with an alternative. The only thing left is Signal/SignalHandler, which AFAIK still has no alternative outside the sun.* packages.

[samus]

The move from javax to jakarta was not really connected to the changes in the language. It is very much recommended to not do these upgrades simultaneously.

[MBCook]

Right. It was a copyright issue, I know.

We didn’t do that one giant jump. We moved from 8 to 17 in one step, then in a separate step upgraded Tomcat requiring the jakarta changes later.

I guess I tend to think of them as one “modernizing“ combo even though they’re not.

[samus]

Indeed, exactly the same process we did.

[cesarb]

> The move from javax to jakarta was not really connected to the changes in the language.

It sort of was; it was caused by Java no longer coming with the J2EE libraries. Before that, J2EE could be considered part of Java; now that it's a separate project, they were forced to rename the packages.

[samus]

The JDK didn't come with these packages anymore. They were never part of core Java.

[pjmlp]

Yeah, Java 9 was the Python 3 moment of the ecosystem, however it has been sorted out for ages.

[samus]

Not comparable; Python 3 changed the source language. While for most programs complying with standard Java nothing had to be changed at all.

[pjmlp]

Yes it was, your Java 8 code won't compile in Java 9, if using anything that was removed or blocked due to the modules changes, library and runtime are part of the language.

A programming language isn't only grammar and semantics.

[samus]

The affected APIs were from packages where is is easy to tell from the name that they were not part of the standard.

These can be very useful in certain circumstances, but it should have always been clear that there is a risk they could one day be changed in an incompatible way or removed.

[pjmlp]

Does not change the fact that existing code, or existing JARs could not run any longer, and had to be rewriten.

When code breaks, the user doesn't care about the details of the root cause, it stays broken.

[samus]

That code was never compatible with standard Java to begin with, therefore nobody should have been surprised. It would have never run on a JVM that didn't bother to implement the same internal APIs.

Crucially, if the OpenJDK project had removed or changed these internal APIs the result would have been all the same. But it's simply unreasonable to expect Oracle to also maintain backwards compatibility there.

[foobarchu]

For what it's worth, I had absolutely no hurdles migrating from 17 to 21 recently. Everything worked fine, the only minor issues were in upgrading Gradle at the same time (which was only tangential)

[lisbbb]

Best of luck to you.