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