ActiveMQ on Java 25 #1563

jeanouii · 2025-12-16T23:20:05Z

No need to review, this is a temp PR I'll kill whenever I have more visibility on what now fails on Java 25

activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java

gemmellr

This should really be enforcing that Java 24+ is used for the release process since its required for this to be of any worth to end users.

An earlier PR is still open to require 21+ since Java 21+ wasnt used for the previous release when it should have been, though that PR (#1532) requires changes as its somewhat out of date now

(I required 25 to release elsewhere, saves changing it later and noone should be really be using 24 now anyway)

activemq-broker/src/main/java24/org/apache/activemq/broker/jmx/SubjectShim.java

activemq-broker/pom.xml

gemmellr · 2026-02-05T10:20:53Z

activemq-client/src/main/java/org/apache/activemq/thread/TaskRunnerFactory.java

+    private void assertJDK21VirtualThreadSupport() {
+        if(!(Runtime.version().feature() >= 21)) {
+            LOG.error("Virtual Thread support requires JDK 21 or higher");
+            throw new IllegalStateException("Virtual Thread support requires JDK 21 or higher");
+        }
+    }
+


The cleanup seems fine, but a thought for later would be....is there any need for all the reflection above and this runtime version checking, when the client jar is already a multi-release jar requiring Java 21 (and soon 24[/25]) to release it? Could maybe have a [couple variants of] trivial delegate class.

This was a refactoring of @mattrpav 's code. So I'd let him reply.
I agree that having the assertion to fail would be weird because that would mean the JVM could not read the MRJAR but still run in some way this class.

activemq-unit-tests/pom.xml

jeanouii · 2026-02-05T12:19:50Z

@gemmellr Thanks a lot for the detailed review. I grab back the branch and address the feedback.

jeanouii · 2026-02-09T15:53:49Z

All feedback addressed
Ok to merge @gemmellr and @mattrpav ?

gemmellr · 2026-02-09T16:52:41Z

I'll leave the test config changes to Matt, not sure whats wanted or has been discussed there.

It doesnt look like you covered this bit of my earlier review. Either the original PR needs updated and merged before this one so this can update things, or this one should just do the necessary, to avoid a repeat of the previous releasing issue.

This should really be enforcing that Java 24+ is used for the release process since its required for this to be of any worth to end users.

An earlier PR is still open to require 21+ since Java 21+ wasnt used for the previous release when it should have been, though that PR (#1532) requires changes as its somewhat out of date now

(I required 25 to release elsewhere, saves changing it later and noone should be really be using 24 now anyway)

#1563 (review)

jeanouii · 2026-02-09T19:09:45Z

@gemmellr I was waiting for Matt to speak, but you are correct, I'll add that in the same PR so it's autonomous. I think it need a JIRA as well.

… test to remove SecurityManager Co-authored-by: Gurpartap Singh <gurpartap0306>

Ensure builds under Java 21 will still work with Security Manager Only run required tests

Use Java 25 compatible version of Mockito Use Mockito Agent because self attaching an agent is now unavailable since Java 21+ Split integration tests (MRJAR dependent) into a specific integration-test phase so they use the jar in the classpath Do not rely on activeByDefault because when other profiles activate, quick becomes inactive

… the API will be removed anyways

…id the failsafe integration tests

jeanouii · 2026-02-10T06:58:54Z

@gemmellr I've now added the enforcer plugin in the apache-release profile to make sure we release the MRJAR supporting Java 21 and Java 24.
I've removed the rule for the Maven version even though to be honest, I prefer it to be explicit like plugin versions or java compiler version. It's a personal preference and I'm fine if community prefers to yank it.
Let me know if that's ok, so I can create the issue in JIRA and then, squash update the commit messages to clean everything up

gemmellr · 2026-02-10T17:51:07Z

@gemmellr I've now added the enforcer plugin in the apache-release profile to make sure we release the MRJAR supporting Java 21 and Java 24. I've removed the rule for the Maven version even though to be honest, I prefer it to be explicit like plugin versions or java compiler version. It's a personal preference and I'm fine if community prefers to yank it. Let me know if that's ok, so I can create the issue in JIRA and then, squash update the commit messages to clean everything up

There is a property used in the parent for the maven version enforcement, you could set that if you wanted it to be specified locally more obviously.

It is personal preference as you say. I dont know what others here might prefer. I definitely prefer to use the parent pom for a lot that is possible (but not everything; I set/override the compiler properties locally) in order to make our poms more concise. Most especially all the plugin versions possible. Users dont really [need to] care about our plugin versions (they have their own plugin versions) so long as things still work, and the constant plugin version upgrade churn otherwise mostly just distracts from other far more meaningful dependency etc changes that users actually are more affected by and likely to be more interested in. I find using the parent versions removes a bunch of that noise, and using the same parent across different components can also mean more consistency among which plugins are being used (albeit, in general all the plugins do then use wildly inconsistent deps, so you still end up needing to grab lots of different versions of the same plugin deps regardless). Its still trivial to see what is actually being used with e.g help:effective-pom, or just running the build.

jeanouii · 2026-02-10T19:34:16Z

Yeah, I have similar preferences. Sometimes I prefer to just be explicit as opposed to think other will go a research. I have bad experience on this. Also sometimes updating just one thing (parent pom for example) will break everything. So parent pom is just an organizational (group) thing for me. I tend myself to put as minimum as possible inside. Add checkstyle rules, deployments rules, rat, and plugins required for that.
Then everything is explicit in project parent pom. That's my preference and I understand we don't have all the same experience and preferences.
If current version (in PR) looks like a good compromise, I'm fine with it.
Like we say in other projects, as soon as it moves the project forward and it does not break things, we can adjust if needed in the future. It does not need to be pixel perfect.

jbonofre

The PR looks good to me.
I just have a couple of questions:

verify vs test in the CI (just curious)
the DataFileFactory and such don't seem directly related with Java 25 (only the Subject is imho). I'm fine to include it, but to "simplify" the review, it would be great to have PR specifically to the change intent. Just a nit.

Great one @jeanouii !

jbonofre · 2026-02-11T11:12:39Z

.github/workflows/ci-nightly.yml

          distribution: temurin
      - name: Test
-        run: mvn -B -e -fae test
+        run: mvn -B -e -fae verify


Any specific reason to use verify here more than test ? I'm just curious.

Yes it was mostly due to the introduction of failsafe to delay the execution of tests using the MRJAR because the jar is created only after the test phase. So tests using MRJAR were postponed to run only during the integration test phase. So if you use test and not verify you won't run them.
In the end, I could have reverted this because Robbie requested instead to change the phase of the JAR plugin so the MRJAR is built in the process classes phase and therefor it's visible to the test plugin. Does not hurt. Could have been removed

.github/workflows/ci-quick.yml

jeanouii force-pushed the NO-JIRA-Jenkinsfile-jdk-25_rev2 branch from 238395b to ec7682e Compare December 17, 2025 15:51

jeanouii force-pushed the NO-JIRA-Jenkinsfile-jdk-25_rev2 branch 4 times, most recently from 0feb22e to 9c4e4ac Compare January 12, 2026 09:25

jeanouii force-pushed the NO-JIRA-Jenkinsfile-jdk-25_rev2 branch from 9c4e4ac to 1922d5b Compare January 14, 2026 17:20

jeanouii changed the title ~~WIP - JL temp work~~ ActiveMQ on Java 25 Jan 15, 2026

jeanouii force-pushed the NO-JIRA-Jenkinsfile-jdk-25_rev2 branch 7 times, most recently from ea87cc1 to 367568b Compare January 23, 2026 08:21

jeanouii force-pushed the NO-JIRA-Jenkinsfile-jdk-25_rev2 branch 2 times, most recently from cf803e8 to 486e60f Compare February 2, 2026 09:48

jeanouii force-pushed the NO-JIRA-Jenkinsfile-jdk-25_rev2 branch 2 times, most recently from af06564 to bfc0690 Compare February 4, 2026 18:46

mattrpav reviewed Feb 4, 2026

View reviewed changes

activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java Outdated Show resolved Hide resolved

gemmellr reviewed Feb 5, 2026

View reviewed changes

jeanouii force-pushed the NO-JIRA-Jenkinsfile-jdk-25_rev2 branch from bfc0690 to e876d81 Compare February 5, 2026 13:52

jeanouii and others added 5 commits February 10, 2026 07:55

Bind to an ephemeral port instead to avoid conflicts

b43b882

[#] NO-JIRA: Update Jenkinsfile to add JDK 25

e0d9c41

[AMQ-9563] Add a SubjectShim to support JAAS API JDK 24+

c8261e8

[AMQ-9366] Add DataFileFactroy to KahaDBPersistenceAdapter and update…

184c64c

… test to remove SecurityManager Co-authored-by: Gurpartap Singh <gurpartap0306>

Add support for Java 25 in CI configurations

15c6f7f

Ensure builds under Java 21 will still work with Security Manager Only run required tests

jeanouii added 5 commits February 10, 2026 07:55

Remove unused import for AccessController in SubjectShim.java because…

11b6fa3

… the API will be removed anyways

Do not use * imports

9b5e101

Attempt to build the MRJAR earlier so tests can use it and we can avo…

a17b795

…id the failsafe integration tests

Update Maven Enforcer Plugin to require Java 24+ for builds

1de8b1c

jeanouii force-pushed the NO-JIRA-Jenkinsfile-jdk-25_rev2 branch from e876d81 to 1de8b1c Compare February 10, 2026 06:55

jbonofre approved these changes Feb 11, 2026

View reviewed changes

jeanouii merged commit b31e804 into apache:main Feb 11, 2026
10 checks passed

ActiveMQ on Java 25 #1563

ActiveMQ on Java 25 #1563

Conversation

jeanouii commented Dec 16, 2025

Uh oh!

Uh oh!

gemmellr left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

gemmellr Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

jeanouii Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jeanouii commented Feb 5, 2026

Uh oh!

jeanouii commented Feb 9, 2026

Uh oh!

gemmellr commented Feb 9, 2026

Uh oh!

jeanouii commented Feb 9, 2026

Uh oh!

jeanouii commented Feb 10, 2026

Uh oh!

gemmellr commented Feb 10, 2026

Uh oh!

jeanouii commented Feb 10, 2026

Uh oh!

jbonofre left a comment

Choose a reason for hiding this comment

Uh oh!

jbonofre Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

jeanouii Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants