base image in jdk21; fix link in readme

[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.