fix: normalize java runtime qualifiers in maven version comparisons

[jamestexas]

Fix: Normalize Java runtime qualifiers in Maven version comparisons

Problem

Maven/Java packages may include JRE/JDK runtime qualifiers in filenames (.jreNN, .jdkNN), but these qualifiers may not appear in the JAR's internal version metadata (from MANIFEST.MF).

When Grype compares versions:

• Scanned package version: 12.10.2 (extracted from JAR metadata)
• Advisory fixed version: 12.10.2.jre11 (from advisory database)
• Result: Comparison fails as 12.10.2 ≠ 12.10.2.jre11 → False positive CVE reported

The runtime qualifiers don't affect semantic versioning and should be normalized before comparison.

Solution

Strip .jre<digits> and .jdk<digits> suffixes before Maven version parsing, following the existing pattern used for other version qualifiers (RELEASE, FINAL, GA).

Behavior after fix:

• 12.10.2 == 12.10.2.jre11 ✅
• 12.10.2.jre11 == 12.10.2.jdk17 ✅
• 12.10.1 < 12.10.2.jre11 ✅ (actual version differences preserved)

Testing

• Added 7 test cases covering JRE/JDK qualifier scenarios
• All existing version package tests pass (no regressions)
• Test coverage includes: equal versions with different qualifiers, qualifier combinations, and real version differences across qualified versions

References

• Upstream library: github.com/masahiro331/go-mvn-version (does not normalize runtime qualifiers)
• Affected packages: Maven/Java libraries that use JRE/JDK qualifiers in distribution names

[jamestexas]

When researching this a bit more, I found that the suffix is non-standard for Maven parsing. It supports . as a delimiter, but treats jre11 as an unknown qualifier that sorts after known ones (alpha, beta, rc, ga, etc.), which breaks version matching.

I believe the fix is still appropriate, but let me know if I should be approaching this differently!

[jamestexas]

Thank you for the review and help!

[bdemeo12]

Hi Grype!

I'm looking to understand your fix for this issue. From my understanding, jre8 and jre11 are different java runtimes, so it's possible that they have different code/dependencies to support the different runtimes, meaning that a bug in jre8, could not appear in jre11, and vice versa.

By stripping all jreXX and jdkXX suffixes before comparing versions, is it possible that this could result in over reporting vulns?

Thank you!