ActiveMQ on Java 25 #1563
ActiveMQ on Java 25 #1563
Conversation
jeanouii
force-pushed
the
NO-JIRA-Jenkinsfile-jdk-25_rev2
branch
from
238395b to
ec7682e
Compare
jeanouii
force-pushed
the
NO-JIRA-Jenkinsfile-jdk-25_rev2
branch
4 times, most recently
from
0feb22e to
9c4e4ac
Compare
jeanouii
force-pushed
the
NO-JIRA-Jenkinsfile-jdk-25_rev2
branch
from
9c4e4ac to
1922d5b
Compare
jeanouii
force-pushed
the
NO-JIRA-Jenkinsfile-jdk-25_rev2
branch
7 times, most recently
from
ea87cc1 to
367568b
Compare
jeanouii
force-pushed
the
NO-JIRA-Jenkinsfile-jdk-25_rev2
branch
2 times, most recently
from
cf803e8 to
486e60f
Compare
jeanouii
force-pushed
the
NO-JIRA-Jenkinsfile-jdk-25_rev2
branch
2 times, most recently
from
af06564 to
bfc0690
Compare
activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java
Outdated
Show resolved
Hide resolved
gemmellr
left a comment
gemmellr
left a comment
There was a problem hiding this comment.
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
Outdated
Show resolved
Hide resolved
| 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"); | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
@gemmellr Thanks a lot for the detailed review. I grab back the branch and address the feedback. |
… 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
force-pushed
the
NO-JIRA-Jenkinsfile-jdk-25_rev2
branch
from
bfc0690 to
e876d81
Compare
|
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.
|
|
@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. |
3 participants
No need to review, this is a temp PR I'll kill whenever I have more visibility on what now fails on Java 25