Post

@assertj.github.io

For AssertJ 4, we wanted to upgrade to Java 17. However, we are discussing whether to stay on 8 or upgrade to 11. The main reason is to keep our effort reasonable and continue supporting users who cannot upgrade yet (e.g., RHEL 7 users under ELS). Any strong reason to keep upgrading to Java 17?

23/12/24, 9:10 am2 reposts2 likes

Bananeweizen

@bananeweizen.github.io

23 Dec 2024

Please read openjdk.org/jeps/14. It explains why it's not a good idea to have popular Java libraries all remain on old versions for compatibility with their large user base. It also suggests a way out. I encourage you to upgrade at least to 17 (better 21), so all the new Java features can be used.

openjdk.orgJEP 14: The Tip & Tail Model of Library Development

Vasili Gulevich

@basilevs83.bsky.social

23 Dec 2024

How many tails do you suggest such libraries support? Libraries with large userbases would have to support at least all active LTS versions of Java, which is not a trivial count.

Bananeweizen

@bananeweizen.github.io

23 Dec 2024

IMO the number of tails isn't important, assuming CI is automated. It's more important to reduce the number of backported changes. If a library would only fix security issues (like CVEs for itself and its dependencies), that should be very small. Not sure if I ever saw a secur. fix for AssertJ yet.

Bananeweizen

@bananeweizen.github.io

23 Dec 2024

For those who like video more than a long JEP text, nipafx explains this also in www.youtube.com/watch?v=ozUE...

youtube.comRelease Your (Java) Projects Like OpenJDK With Tip & Tail - Inside Java Newscast #79YouTube video by Java