### Problem to solve The current Gemnasium Maven analyzer supports multiple Java versions (8, 11, 17, 21) via `DS_JAVA_VERSION`, creating significant maintenance overhead. However, since the shift to dependency collection only (via `maven-dependency-plugin:tree` with `requiresDependencyCollection`), we may no longer need version-specific Java environments because: - Only POM metadata is fetched and parsed (no JAR downloads for project dependencies) - No source code compilation occurs - No tests are executed - The JVM doesn't need to match the target compilation version for dependency resolution ### Proposal **Objective** Validate that a single modern Java LTS version (Java 21 or 25) can successfully generate dependency graphs for Maven projects originally targeting older Java versions (8, 11, 17). **Hypothesis** 95%+ of Maven projects should work with a single modern Java LTS version when only performing dependency collection, as stated in the [spike proposal](https://gitlab.com/gitlab-org/gitlab/-/issues/582607#note_2931370748). **Experiment Design** 1. **Test Matrix** - Find public Maven projects of substantial size/complexity that explicitly require Java 8, 11, 17, or 21 - Run `mvn dependency:tree -DoutputType=json -DoutputFile=maven.graph.json -Denforcer.skip=true` using Java 25 (or 21 as fallback) - Document success/failure rates per original target Java version - Validate graph file content against once created using the original target java version 2. **Test Projects Selection Criteria** - Avoid "hello world" projects - Try to include projects with: - Maven Enforcer Plugin rules - Parent POM structures - Multi-module projects - Various dependency scopes (compile, test, provided, runtime) 3. **Failure Analysis** - Document specific failure modes encountered - Categorize failures: - Maven Enforcer Plugin (mitigated with `-Denforcer.skip=true`) - Plugins bound to `validate`/`initialize` phases incompatible with modern Java - Other blockers 4. **Java Runtime Image Selection Criteria** There are multiple Java runtime distributions available. The PoC should evaluate and document the rationale for image selection based on Distribution, image size, FIPS compliance and licenssing. Current GitLab Patterns: - DS SBOM documentation uses: `maven:3.9.9-eclipse-temurin-21` - API Discovery uses: `eclipse-temurin:17-jre-alpine` - Gemnasium currently bundles java-17-openjdk in a ubi-micro image **Test Command** ```bash # Using official Maven Docker image with Java 21/25 docker run -it --rm -v $(pwd):/project -w /project maven:3.9-eclipse-temurin-25 \ mvn dependency:tree -DoutputType=json -DoutputFile=maven.graph.json -Denforcer.skip=true ``` **Success Criteria** >1. [ ] Acceptable success rate (>95%?) across diverse Maven projects targeting Java 8, 11, 17, 21 - Achieved 94.7% success rate (18 out of 19 projects) - Tested projects targeting Java 7-21, ranging from single modules to 244 modules - Covered enterprise frameworks, native code integration, and multi-module projects - Only failure: Java8InAction (JVM crash with Java 25, resolved with Java 21 fallback) >2. [ ] Documented list of failure patterns and potential mitigations - JDK Architecture Changes: jdk.tools, com.sun:tools (tools.jar removed after Java 8) - JavaFX Dependencies: openjfx-78-backport (JavaFX unbundled after Java 8) - Profile-Based Activation: Conditional modules based on JDK version (ZXing, Dubbo) - Mitigation: All differences represent expected JDK evolution or intentional profile-based behavior >3. [ ] Recommendation on Java 21 vs 25 based on compatibility and ecosystem readiness - Recommend Java 25: 94.7% compatibility across diverse projects demonstrates readiness - Modern runtime with current features - Edge case handling: 1 project may require Java 21 fallback - Standard image: maven:3.9-eclipse-temurin-25 >4. [ ] FIPS compatibility assessment for chosen Java version - FIPS support confirmed via IBM Semeru Runtime JDK 25 - Available image: ibm-semeru-runtimes:open-25-jdk - Enable with: -Dsemeru.fips=true -Dsemeru.customprofile=OpenJCEPlusFIPS.FIPS140-3 - FIPS mode enforces security restrictions (FIPS-compliant keystores required) as expected - Same image supports both FIPS and non-FIPS deployments **Known Risks to Validate** | Risk | Mitigation | Status | |------|------------|--------| | Maven Enforcer Plugin strict Java version rules | `-Denforcer.skip=true` | To validate | | Plugins in `validate`/`initialize` phases incompatible with Java 25 | Document frequency | To validate | | FIPS image compatibility | Check UBI base image availability | To validate | **Expected Outcomes** If successful, this PoC will enable: - **Simpler analyzer implementation**: No version detection logic needed - **Faster CI/CD**: No Java version switching overhead - **Easier maintenance**: Single Docker image to maintain - **Reduced user complexity**: No need to configure `DS_JAVA_VERSION`