Skip to content

feat!: require minimum JDK 17 - #803

Closed
jeremylong wants to merge 1 commit into
CycloneDX:masterfrom
jeremylong:feature/jdk17
Closed

feat!: require minimum JDK 17#803
jeremylong wants to merge 1 commit into
CycloneDX:masterfrom
jeremylong:feature/jdk17

Conversation

@jeremylong

Copy link
Copy Markdown
Contributor

BREAKING CHANGE: Drop support for JDK 8 and JDK 11. The minimum required Java version is now 17.

This change is to support the upgrade of the cyclonedx-core-java library, which now requires JDK 17.0. See the discussion and PR.

BREAKING CHANGE: Drop support for JDK 8 and JDK 11. The minimum
required Java version is now 17.

Signed-off-by: Jeremy Long <jeremy.long@gmail.com>
@jeremylong
jeremylong requested a review from a team as a code owner March 14, 2026 18:47
@jeremylong

Copy link
Copy Markdown
Contributor Author

Once the project utilizes Java 17.0+ we can upgrade the cyclonedx-java-core library via PR #786. This is being done to reduce hash computation time and SBOM size using the configuration options added in PR #785.

@skhokhlov

Copy link
Copy Markdown
Member

Thanks for working on this. I understand the motivation - cyclonedx-core-java is moving to Java 17, offers new features, and that creates a natural pull upstream. However I'd like to raise a concern before this gets merged.

I looked at the linked discussion and PR - there is no clear technical reason given for why cyclonedx-core-java itself had to drop Java 8 compatibility. No specific API / runtime dependency / feature that requires it. It reads more like “let’s upgrade because we can” which is not a sufficient justification for cascading that decision to every downstream tool. Nothing stops you from compiling with newer Java to Java 8 compatible bytecode. So the question here is what specifically makes Java 8 compatibility impossible?

Dropping Java 8 and 11 support is a breaking change for a significant portion of the user base, particularly enterprises, which are often constrained to older Java versions. It can be because of vendor support or longed-lived development cycles. Orcale's extended support for Java 8 runs until 2030 meaning there are plenty of legitimate environments still running it. Pushing them off the CycloneDX tooling without a solid reason is rough.

Please get me right - I’m not saying never upgrade. I’m just asking for a better reason than “because the core library did it”. Would love to hear if there's a concrete technical constraint I'm missing.

@jeremylong

Copy link
Copy Markdown
Contributor Author

Completely understand your concern and I agree. Even with OWASP dependency-check, I only went to 11.0 after I knew several large U.S. banks had finished migration away from 8 - and ODC is still at 11.0 support (we have several libraries that we needed to upgrade and they no longer supported 8). I'm fine pushing back on the cyclonedx-java-core project to support Java 11.

@nscuro

nscuro commented Mar 15, 2026

Copy link
Copy Markdown
Member

Hi, the primary reason is "ecosystem pressure". In the Slack discussion I linked in the core lib PR, I posted:

What are everyone’s thoughts on raising the Java baseline in cyclonedx-core-java? The current baseline is 8, and while 8 is not technically EOL yet, the ecosystem as a whole is moving on.

JUnit 6 for example has raised its baseline to Java 17. I wouldn’t expect this library to live on the cutting edge of Java versions, but I’d like it to move from 8 to 11 at least.

Since then, also the JSON schema validator we depend on has raised their baseline to 17. There is never a perfect time to make these breaking changes unfortunately, but we have to start somewhere.

@skhokhlov Orcale's extended support for Java 8 runs until 2030 meaning there are plenty of legitimate environments still running it.

It's great that enterprises can buy extended support for old Java versions, but that doesn't address the technical debt caused by libraries that stop supporting those versions. Spring 6 (released 3 years ago) also requires Java 17, as do many other enterprise-grade frameworks and libraries.

To be clear I am not the one making calls here, so if there is legitimate reason to reverse this I'm sure we can figure something out.

@jeremylong I'm fine pushing back on the cyclonedx-java-core project to support Java 11.

Based on @skhokhlov's comment my impression is that even 11 is too high?

@jeremylong

Copy link
Copy Markdown
Contributor Author

While there are legitimate environments that are running Java 8 - what I've experienced is that they are rarely using the latest dev tools (i.e., running older versions of everything - not just the JDK). With dependency-check we did end Java 8 support - you can still analyze code targeting Java 8. However, you have to use a newer JRE to perform the analysis. We recently added telemetry to dependency-check and we are still seeing Java 11 usage:
downloaded-by-user-agent-scan-Dependency-Check-2026-03-16T11_40_08 891Z

As such, I would expect similar usage for the cyclonedx-gradle-plugin. Thus, supporting Java 11 (and possibly 8) should likely continue. I know this isn't ideal for tool maintainers - but it is the reality of the landscape.

Comment thread build.gradle.kts
useJUnitPlatform()
maxParallelForks = (Runtime.getRuntime().availableProcessors() / 2).coerceAtLeast(1)
if (version >= 11) {
if (version >= 17) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no reason to retain the condition here, it's always true now.

@nscuro

nscuro commented Mar 27, 2026

Copy link
Copy Markdown
Member

I have started a new discussion on potentially lowering the Java baseline: https://cyclonedx.slack.com/archives/CUYQ4K67M/p1774605342557269

@MalickBurger

Copy link
Copy Markdown
Contributor

I am closing this for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants