Java’s ecosystem keeps doing what mature ecosystems do: a steady stream of JEPs, point releases, security fixes, and release candidates across OpenJDK, Spring, Micrometer, Camel, JBang, and Jakarta EE.
Hari
Java’s ecosystem keeps doing what mature ecosystems do: a steady stream of JEPs, point releases, security fixes, and release candidates across OpenJDK, Spring, Micrometer, Camel, JBang, and Jakarta EE.
Hari
There’s a lot happening right now, like the introduction of JEP 432 and updates to Spring Framework 6.
When you say “a lot of moving parts, ” are you thinking more about the JDK/JEP changes or the framework side where you upgrade Spring/Quarkus and suddenly a transitive dependency pulls in a fresh CVE? I could be wrong here.
Oof, “upgrade Spring and a transitive pulls in a surprise CVE” is the part that gets me, because the JDK/JEP side usually feels way more predictable once you pick an LTS and stick to it. I’m not sure what Hari meant, but are you talking about the Maven/Gradle graph shifting under you (like BOM changes or a new minor of Netty/Jackson showing up) more than the JDK itself?
@WaffleFries yeah, the BOM is usually where the mess starts.
The JDK side is mostly boring in the good way. The dependency side is where a parent POM bumps a managed version and suddenly Jackson or Netty moves under your feet. We had that happen with a Spring upgrade last year — nothing “changed” in our code, but the resolved tree did.
We started diffing the resolved dependency tree in CI on platform bumps. It’s a bit grim, but at least the surprise turns into an explicit review instead of a 2am CVE hunt.
Okay so diffing the resolved tree in CI is grim but it’s basically the only way I’ve found to make “nothing changed” stop being a lie. We started pinning a lockfile-ish output (mvn dependency:tree dumped to an artifact) per platform line so PRs show exactly which transitive jars moved, and it cut way down on the spooky-action-at-a-distance upgrades.
We tried the Gradle lockfile route too and yeah, it was the first time “no dependency changes” stopped being fiction — but dumping mvn dependency:tree per platform line sounds like a lot of artifacts to babysit, how are you keeping those trees stable (same ordering/formatting) so PR diffs only show real jar movement? I might be wrong here.
:: Copyright KIRUPA 2024 //--