Docker image update to JDK 25 and README updates

[colinwerner]

We now use JDK 21 and we have some custom code that we add to the base activemq classic image that is currently compiling against jdk17. We want to move everything to jdk21.

I don't see any down side here...

[mattrpav]

Changing the JDK major version shouldn’t happen in a point release.

Users are free to use this as an example as to how to build their own custom containers as well.

v6.2.x is released with JDK 17 as baseline, we should maintain that version alignment and not change that on users.

[colinwerner]

That makes total sense, @mattrpav. I completely see your point regarding runtime predictability and keeping a consistent baseline for the 6.2. x line.

I'll leave this MR open so we don't lose visibility on it, and we can target it for whenever you're ready to shift the baseline in a future release, perhaps in 6.3.x? In the meantime, we are compiling our code into JDK17...

[jbonofre]

@mattrpav is right. Also, the Docker image should not be updated without updated the rest of the project (CI included).
Today, even on main, the JDK version is 17 still.

There's two reasons for that:

1. Spring requirements (for the version we are using)
2. SecurityManager change

The Java version update should be a complete PR (https://activemq.apache.org/components/classic/download/).

Are you proposing to bump Java 21 minimum?

[mattrpav]

Temurin JDK 17 LTS support plans to go through October of 2027. As a foundational platform, there is value in ActiveMQ supporting the widest range of JDK as possible.

v6.3.0 provide Multi-release jar for Virtual Thread support, but I don’t see a reason to change the baseline version then.

The community provided containers provide a sample and aren’t intended to support all use cases or end user needs

[colinwerner]

Thanks for the additional context @jbonofre and @mattrpav. That makes perfect sense. To clarify, my initial thought was just to bump the container's runtime environment to JDK 21 (while keeping the codebase compiled for 17), as JDK 17 limits what users can run alongside or extend the container with, whereas a JDK 21 environment provides a broader, more modern baseline for the image ecosystem. But I completely see how the SecurityManager deprecation, Spring dependencies, and lack of CI testing on 21 make that unsafe right now.

Since the project isn't ready for a JDK 21 runtime baseline yet, I'll leave this MR open as a draft/placeholder so we don't lose visibility on it. We can dust it off whenever the rest of the project and CI are ready to officially validate against Java 21.

[github-actions]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[jbonofre]

That should be 25 now

[colinwerner]

@jbonofre you beat me to it with #2257, so I rebased and dropped my Dockerfile change.

One thing I noticed and don't quite yet understand is that docker-java-version in the root pom is still 17, and the docker and docker-deploy profiles pass it as a build arg, which overrides the ARG default. So mvn -Pdocker builds a 17 image while docker build gives 25. I set the property to 25 here so the two agree.

I verified it both ways locally; the default build pulls 25-jre, and the image comes out Temurin-25.0.3+9, and forcing -Ddocker-java-version=17 pulls 17-jre. Broker starts up fine on 25.

The 6.3.0 image on docker hub is already 25, though, so I am guessing the release was built with -Ddocker-java-version=25 passed in? Can you confirm? If so, this would just remove the need for the override.

[mattrpav]

The Dockerfile has static value and is not processed as a filtered-resource to pickup the maven property

ref:

activemq/assembly/src/docker/Dockerfile

Line 19 in a68a3bf

ARG java_version=25

[colinwerner]

@mattrpav Right, it is not filtered. It comes through as a build arg instead; the docker profiles pass java_version via fabric8's args block in assembly/pom.xml, which overrides the ARG default. On main as-is:

mvn clean install -DskipTests -Pdocker -Ddocker-java-version=17
docker run --rm apache/activemq:6.4.0-SNAPSHOT java -version

gives Temurin-17.0.19+10. Without the -D you get 25. Same Dockerfile, only the property changed.

So mvn -Pdocker quietly builds 17 today; this just sets the property to 25 so they match.

That said, dropping the arg and the property might be the better fix. The version is declared in two places right now, and they can drift, which is what happened here; #2257 updated the Dockerfile and the property stayed at 17. If it only lives in the Dockerfile, then docker build and mvn -Pdocker cannot disagree, and there is no -D to remember. The one thing it costs is overriding the JDK per build from the command line. Happy to redo it that way if you prefer. Either way, please let me know...

[mattrpav]

LGTM