[
https://issues.apache.org/jira/browse/ARTEMIS-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18031441#comment-18031441
]
Robbie Gemmell commented on ARTEMIS-5711:
-----------------------------------------
Note that whilst building or running, there will still be warnings emitted, e.g
due to classes making use of functionality from {_}sun.misc.Unsafe{_}, or
loading libraries using {_}java.lang.System::loadLibrary{_}.
E.g on broker startup:
{noformat}
WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::allocateMemory has been called by
io.netty.util.internal.PlatformDependent0$2
(file:/path/to/apache-artemis-2.44.0-SNAPSHOT-bin/apache-artemis-2.44.0-SNAPSHOT/lib/netty-common-4.1.128.Final.jar)
WARNING: Please consider reporting this to the maintainers of class
io.netty.util.internal.PlatformDependent0$2
WARNING: sun.misc.Unsafe::allocateMemory will be removed in a future release
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::loadLibrary has been called by
org.apache.activemq.artemis.nativo.jlibaio.LibaioContext in an unnamed module
(file:/path/to/apache-artemis-2.44.0-SNAPSHOT-bin/apache-artemis-2.44.0-SNAPSHOT/lib/activemq-artemis-native-2.0.0.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers
in this module
WARNING: Restricted methods will be blocked in a future release unless native
access is enabled
{noformat}
Netty already stopped using Unsafe by default on JDK24+ in early 4.2 releases,
and then went back to using it for performance reasons. I believe there is a
flag to change the behaviour, but probably not one we want to use for the same
reason they swtiched the default back to using Unsafe for now. The latter
warning we could possibly suppress with the mentioned flag in future.
E.g on building using Maven 3.9.11 on Java 25:
{noformat}
WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::staticFieldBase has been called by
com.google.inject.internal.aop.HiddenClassDefiner
(file:/path/to/apache-maven-3.9.11/lib/guice-5.1.0-classes.jar)
WARNING: Please consider reporting this to the maintainers of class
com.google.inject.internal.aop.HiddenClassDefiner
WARNING: sun.misc.Unsafe::staticFieldBase will be removed in a future release
{noformat}
This is coming from the Maven implemetnation, so the fix will need be there.
> Enable support for building and running on Java 25
> --------------------------------------------------
>
> Key: ARTEMIS-5711
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5711
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Affects Versions: 2.43.0
> Reporter: Robbie Gemmell
> Assignee: Robbie Gemmell
> Priority: Major
> Fix For: 2.44.0
>
>
> The Java SecurityManager was deprecated in Java 17 for removal, with no aim
> to replace the functionality. The Subject class also uses parts of the
> SecurityManager API, but it has its own usages beyond the SecurityManager
> functionality, so replacement functionality for the affected methods were
> added in Java 18 in the Subject.current() and Subject.callAs(..) methods.
> Java 23 began the process for removing the SecurityManager implementation,
> reimplementing the Subject methods with both the old and newer behaviours,
> and making Subject.getSubject(..) throw UnsupportedOperationException unless
> an option flag is used to enable support for a SecurityManager (still without
> actually needing to have an SM in use). [Java 24 actually removed the
> SecurityManager implementation|https://openjdk.org/jeps/486] , and made
> Subject.getSubject() always throw UnsupportedOperationException. As a result
> of these changes, building and testing Artemis does not work on Java 23+
> currently, and there are issues running on Java 23+ without at least
> disabling the AuditLogging functionality that uses Subject.getSubject(..).
> These issues can be seen discussed in the referenced ARTEMIS-4975 and
> ARTEMIS-5374. Though the other SecurityManager APIs are still present and
> 'functional' (effectively passthroughs), the APIs will be removed in a future
> JDK which will itself present another issue to building and running on those
> JDKs
> This Jira seeks to enable building/testing and running on Java 25 and beyond
> by addressing these issues. To achieve this, references to the
> SecurityManager / Subject APIs affected will be contained to a wrapper shim,
> with an implementation using the old methods targeting Java 17-23, and a
> second shim implementation using the new Subject methods (and not using any
> SecurityManager methods at all) targeting Java 24+ and thus enabling Java 25
> support and avoiding issues when the old APIs are later removed. (NOTE: on
> Java 23 this approach will still requiring either the flag to enable
> SecurityManager support, or disabling the audit logging to avoid it calling
> Subject.getSubject(..), if not just upgrading to e.g a supported Java 25
> release)
> Whilst it will still be possible to run/build/test on Java 17+, a side effect
> of this approach will be requiring that releases are created using Java 25,
> which was [discussed and agreed on the mailing
> lists|https://lists.apache.org/thread/7vspfpmfnfqd6fmvpjzm0kr59b5dm9j2].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
