Lower JDK requirement to 11

[pfichtner]

I would like to upgrade to jmolecules 2.0.0, but currently I can’t, because the published artifacts require Java 17. My project still uses Java 11, so upgrading breaks compatibility.
The reason I cannot upgrade is that I maintain a library which intentionally keeps its baseline low to remain usable by a wide range of projects, including those still on Java 11. Requiring Java 17 in jmolecules would force my own library to raise its minimum version and would break compatibility for many downstream users.

After examining the changes, it appears that jmolecules itself does not use any Java 17 language features or Java 17 APIs.
The only reason for the Java 17 requirement seems to be the upgrade of the test suite to JUnit 6, which requires Java 17.
To verify this, I tested downgrading the test framework to JUnit 5.x and lowering the compiler target to Java 11, and jmolecules compiles successfully without any code changes. This shows that jmolecules itself does not depend on any JUnit 6–specific functionality either.

Because the runtime library code remains fully Java-11-compatible, it should be possible to continue publishing JARs that Java 11 users can consume — without modifying the production code base.

Possible Solutions

Here are several options that would allow jmolecules to publish Java 11–compatible artifacts while still using modern tooling in the project:

1. Build with multiple JDKs using Maven toolchains

Maven can compile main sources with JDK 11 and run tests with JDK 17:

• Compile main with JDK 11
• Compile/run tests with JDK 17
• Publish Java 11 bytecode artifacts

This works with Maven 3; Maven 4 is not required.

2. Use JUnit 5.x instead of JUnit 6

If the project does not rely on JUnit 6-specific features (which it currently doesn't), switching back to JUnit Jupiter 5.x restores Java 11 compatibility without impacting production code.

3. Publish dual artifacts (Java 11 and Java 17)

For example:

• jmolecules-annotations:2.0.0 → Java 17
• jmolecules-annotations-j11:2.0.0 → Java 11

This pattern is used by several libraries that support multiple environments.

4. Post-process bytecode (RetroWeaver / ASM / Retrolambda-like tools)

Technically possible but not recommended.
You could run a bytecode transformer that rewrites class versions to 55.0 (Java 11)

---

Would you consider one of these approaches?

Any of these solutions would make jmolecules 2.x usable for Java 11 users while allowing the project to keep its current test infrastructure. I would be happy to help test or prepare a PR if useful.

[odrotbohm]

It looks like the build is just fine if I flip the project version from Java 17 to 11. Just to make sure we're not talking past each other: you're talking about the jmolecules specification artifact, not any jmolecules-integration bits, right? For the latter, we've just dropped the support for Boot 2.x and to keep things consistent, I would like to keep those on Java 17, if possible.

[pfichtner]

It looks like the build is just fine if I flip the project version from Java 17 to 11. Just to make sure we're not talking past each other: you're talking about the jmolecules specification artifact, not any jmolecules-integration bits, right? For the latter, we've just dropped the support for Boot 2.x and to keep things consistent, I would like to keep those on Java 17, if possible.

Correct, I was talking jut about jmolecules specification artifact. Thanks for checking. Although there is obviously no reason to switch to Java 17, I can understand that you would like to use Java 17 here as well for reasons of consistency.

[odrotbohm]

Would you mind giving the snapshots a try?

[pfichtner]

Would you mind giving the snapshots a try?

Compiled successfully using JDK 11
Thank you Ollie!