Consider updating to a supported version of spring-boot

[MichaelVetter]

There is no OSS support for spring-boot 2.x now and there is a CVE in the currently used version: https://spring.io/security/cve-2024-38807

I saw that the major update to spring-boot 3.x was rejected in #172 and #173 because of the required java version. If there is no special reason to support older java versions please consider a major update of spring-boot.

[humblekofe]

Alternatively you may consider updating to 2.7.22 in which CVE-2024-38807 has been fixed?

[jeremylong]

The CVE is for a local attack... against a CLI...

[jeremylong]

The open-vulnerability-client library has to support Java 11. Unless I split up the library and the vulnz cli into separate projects it would be difficult to jump to Spring 3.

[EugenMayer]

The question that comes with this @jeremylong , how long do you want to support Java11. If this means several years from now, there might be a bigger issue coming up no matter up (while 2.x is rotting).

I get your point, SB 3.x with Java17 is a hurdle, i'am not sure why someone why you need Java11 support.

Assuming I build an application that even compiles to target 1.8 / Java 8, I would have no issues running my build target on a 17/21 JDK, but still using 1.8 as my target. One is not forced to use the JDK for the target at all, thus requiring java17 for the gradle/maven plugins to scan the code is, IMHO, entirely fine. It does not force anybody to upgrade from Java8 or Java11 AFAICS.

[Iridias]

I agree with @EugenMayer - rather sooner than later, you'll have to update.
Staying on an EOL version for an extended period doesn't seem feasible.

[EugenMayer]

I did not really make an argument like "we should not stay / use EOL libraries" - i think @jeremylong is perfectly aware and as he stated, it is not a decision he made out of preference.

@jeremylong has a problem/demand AFAIU: Supporting code-bases compiled against/for Java11

And honestly, Java11 is not that old so one can disregard all the software written on it (yet and surely for a couple of years to come).

This said, we need a solution for that - and i think my solution is:
There is no need to stay on Java11 for the ODCs, since there is no need for the Software compiled against a Java11 to be compiled on a 11JDK. So all a project might need to do to support the new OCDs based on SB3.x and Java17 is, upgrading the JDK to Java17 - but not the software itself.

And to be honest, this should be trivial.

This way the current OCD can also be used for java8 projects too.

[aikebah]

@eugene updating software to work on Java 17 is not always trivial. There is still (to my dismay) a lot of enterprise software that needs to take the hurdle from Java 8 to later. Java 11 support (as the permissive transitional release) has gotten its support period extended by Java vendors for a reason.
From java 11 onward there have been intentional breaking changes further shielding off the Java internals that software should never have been built upon, but unfortunately 'should not' has been proven to not be enough to prevent coders from using it.

[EugenMayer]

@aikebah i would encourage you to read both of my comments once again. I did explicitly mention, that forcing users to update to Java17 is not needed and not practical - still this is the exact point you want to make.

It seems like way to many people still do not understand, that even though you are using a JDK21, you can compile your software to java 1.8 and then run your gradle plugin within on jdk21 since it needs it.

Again, in plain english: We can require gradle/maven ODC clients to required java 17 (a jdk17+) without forcing people to upgrade their java8/11 source code or migrate in any sort.

[aikebah]

@EugenMayer Building Java 8 code that depends on internals of the JDK using JDK17 is something that can actually break the build due to the backward compatibility breaking changes in the JVM. At the very least during test of code that uses nowadays forbidden internals of the JVM.

So 'just swap the JDK that runs your build' is not for every project a solution. For many "it just works", for others it needs explicit dependencies on e.g. Java EE client libraries that were previously bundled with the JVM and for yet others it will simply break as the codebase uses forbidden parts of the core java classes.

[EugenMayer]

The JaxB point you are making is only valid for java8, and this one is no longer supported this library, so there is nobody that is forced to add those libs (while this would be a zero effort anyway). Cannot see this as an effective argument here, to be honest.

So since we are talking about people compiling java11 source code under a JDK17:

Could you please give concrete examples about issues cross-compiling Java11 source/target under a JDK17?

I'am aware of some stuff that has been remove in 9 and 11, but 11 i'am not aware of removals in 17 (beside the jakarta change). But for cross compiling, i simply see nothing / know nothing. But maybe you have concrete experience in pointing at those issues, happy to take those. Thanks!

UPDATE:

Fair point, i was too broad in my statements above that absolutely zero changes need to be done for a java8 app cross compile against jdk 21. Mostly, all you need to do is add the usual jaxb dependencies, but in special cases you might have complications due to illegal class access that has been made stricter (AFAIR rather in java9 and java11). The next big "access restrictions" limits are planned for 23 with the dynamica agent loading (affecting things like Mockito). Still i should have be more concrete for this library, and this would be java11+ (and there is where i see now cross compile issues)

[aikebah]

@EugenMayer for one: https://openjdk.org/jeps/403 does further restrict access to JVM internals from 11 to 17. https://openjdk.org/jeps/372 is another that might break previously working Java 8 codebase that still worked (with deprecation warnings) on JDK 11.

I'm fully with you that devs should try to work as much as possible to use at least 'latest LTS' as the JDK that drives their toolbox to early catch and if possible mitigate forward compatibility issues in the codebase.

For JVM internals (ab)use sometimes the only way to be runtime-compatible is to migrate the code to newly introduced APIs of later Java versions as tests typically run on the same JVM as your toolbox).

For other 'deprecations for removal' devs would have to onboard on 3rd party libs or write replacement code themselves.

Company budgetting practices do not always allow to squeeze in such forward-compatibility upgrades in ongoing maintenance, and most definitely will not allow an unplanned upgrade of JVM major.

In my view as much as feasible build tools/plugins should allow running on an older JDK (as long as it won't prevent correct working on a modern JDK).

Inability to run on modern JDK would be a good reason to bump the minimum required JDK of build tools.

[EugenMayer]

@aikebah thank you very much! I learned that there are way more things that can happen then i experienced when migration a chunk of apps from 6, 8, to 11, 17 and now 21.

Considering your statement, i assume being conservative with the jvm from gradle/maven ODC might be a wise choice.

[jeremylong]

I have made some executive decisions and split the library and cli into separate repositories:

• https://github.com/jeremylong/open-vulnerability-cli
• https://github.com/jeremylong/open-vulnerability-clients

The OVC library needs to stay Java 11 - ideally, it would have been good to keep this at Java 8 but it is getting harder and harder to do that as other libraries bump their base Java version. However, the cli can now be bumped to the latest LTE which will allow the upgrade of spring-boot.

[jeremylong]

The other reason for the split can be found here: #275

[EugenMayer]

Thank you for the hard work!

[EugenMayer]

To keep the momentum i went ahead and upgraded to spring boot 3.4 / Java 17 with #278