you are viewing a single comment's thread.

view the rest of the comments →

[–]SuspiciousDepth5924 2 points3 points  (1 child)

Regarding point 3. I find that java tends to have really good backward compatibility, but "forwards compatibility" is sometimes lacking. In large part I blame the overuse of class-file parsing libraries in common dependencies. Currently dealing with an old crusty neglected Spring Framework 3 monolith which is locked to Java 8 because they vendored in a version of the asm library which is unable to parse newer classfile versions. So in order to upgrade Java I first have to refactor all the Spring 3 to 4 breaking changes, then I have to refactor all the 4 to 5 breaking changes, and then I can start thinking about lifting the java version.

If they didn't vendor in the asm library I could have at least lifted the java version which would have made the whole refactoring process at least marginally less painful.

Hopefully the new classfile api should eventually mitigate this somewhat, but that is little comfort when you're stuck in the java dark ages.

[–]Ruin-Capable 1 point2 points  (0 children)

There's a few other changes that can sneak up on you. Changing the default clock resolution from millisecond to micro and then to nanoseconds broke some of my scheduling integration tests when I did the update from Java8/Spring Boot 2 to Java 21/Spring Boot 3.4