Dependencycheck: Remove Java 7 Compatibility Support

Created on 18 Oct 2018  路  6Comments  路  Source: jeremylong/DependencyCheck

Originally, Java 7 compatibility was enforced due to Jenkins not supporting Java 8 at the time. This is no longer true. The Dependency-Check Jenkins plugin requires Java 8 now.

I propose to increase the enforcement to Java 8, dropping Java 7 support, and in doing so, upgrade all third-party components that have historically been pinned at older versions supporting Java 7. The most notorious of these is Lucene, which could theoretically be upgraded to the latest 7.5.x release.

To my knowledge, apache commons (something or other - StringUtils I think), cannot be upgraded due to jar-hell with Jenkins. But other than that, we should be able to upgrade most components to those that have been compiled and targeted for Java 8.

dependencies

Most helpful comment

There are vulnerable dependencies that, while I doubt they are exploitable in the way they are used in dependency-check, the team decided that a breaking release should be performed to resolve the issues. The upgraded version for the libraries requires Java 8; as such, OWASP dependency-check will now require a minimum JRE/JDK of 8.

All 6 comments

I am in complete agreement with this. In fact - we could even upgrade apache-commons if we bundled dependencies with the shade plugin

I would rather not shade the resulting jar (or at least if we do, provide two variations - shaded and non-shaded). Since the core is essentially a library which is used by Dependency-Track, CodePulse, and others, there may be adverse affects in only providing shaded jars.

I don't know if there's a way to compile and test with an older version of commons, and when packaging/distributing. include a more recent version. Essentially what we would need is an enforcement rule at the method level to ensure compatibility to older versions of commons while still bundling newer versions.

We should be able to shade with no adverse affects. During the shade packaging we simply change the package name for everything core uses in commons-lang3. I'll put this in a separate branch and let you take a look.

Ah - that would be ideal then.

There are vulnerable dependencies that, while I doubt they are exploitable in the way they are used in dependency-check, the team decided that a breaking release should be performed to resolve the issues. The upgraded version for the libraries requires Java 8; as such, OWASP dependency-check will now require a minimum JRE/JDK of 8.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings