[wildfly-dev] Re: Disabling of Security Manager in latest SE 24

I would follow on and say that if you do happen to notice some obscure security-related JDK API which produces an error starting on Java 24, the simplest solution is to wrap it in a version check like this: if (Runtime.version().feature() < 24) { // the call will work } And make sure you are using CI to test on both <24 and >=24 in this case.

On Tue, Nov 19, 2024 at 9:27 AM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > tl;dr; Do not remove security manager calls from WildFly or its > components! Not unless you want and are able to maintain a branch > supporting them for many years. > > > I don't know all the details, but from a few discussions I've seen in the > last hour it seems that the promised removal of runtime support for the > Security Manager[1] has landed in an SE 24 update. > > This change means in an SE 24 environment you can no longer enable the SM > and it will fail if you try. So this will certainly affect our code that's > meant to run on SE 24 and later; we'll need to adapt to not try and turn it > on. > > What this *should not* mean is calls to SM-related APIs in SE will fail. > They should still work; they just don't do any enforcement. This isn't some > odd situation since for decades now the vast majority of calls to SM APIs > don't result in enforcement -- because the user doesn't enable the SM. > > WildFly is going to support Java SE versions where the SM works for many > many more years. It's only in the upcoming WF 35 that we're dropping > support for SE 11. So who knows how much longer we'll need to support SE 21. > > If you break SM support in a component, that stream will no longer be > usable in typical WF! > > We'll need to do things to prepare for the day when SM APIs are removed > from SE and we shouldn't ignore that task. But please don't break things. > > Kudos to those of you like Richard Opalka and James Perkins who are > keeping an eye on things and noticed this promptly. > > [1] https://openjdk.org/jeps/486 > > Best regards, > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > WildFly Project Lead > He/Him/His > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > Privacy Statement: https://www.redhat.com/en/about/privacy-policy > List Archives: > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... > -- - DML • he/him