I'm referring to the more common case, SM is an optional component
determined by admin, Option A is use SM, Option B is don't use SM, but
you wrote code that worked in either scenario. Deployments that chose
Option B have long since forgotten about Option A.
Writing one line:
TRANSFER_FUNDS.checkGuard(null); // possible no op.
Was more elegant than writing:
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new AccountPermission("transfer"));
}
The SecurityException is thrown in Permission::checkGuard.
--
Regards,
Peter
On 7/04/2026 6:46 pm, Alan Bateman wrote:
On 07/04/2026 08:13, Peter Firmstone wrote:
I understand the logic, however the new implementation breaks
backward compatibility with existing bytecode at runtime. Programs
that executed previously without SM on java 23-, will throw
SecurityException, a RuntimeException and exit with Java 24+, this is
unexpected behaviour.
Permission::checkGuard was a convenience method that reduced
boilerplate.
public void checkGuard(Object object) throws SecurityException {
@SuppressWarnings("removal")
SecurityManager sm = System.getSecurityManager();
if (sm != null) sm.checkPermission(this);
}
When SM is null, Java 23 and earlier versions won't execute the
permission check, it's a no op. In Java 24+ it throws an exception
and the program exits, it's basically akin to force enabling
SecurityManager with a strict deny policy. People who don't have
access to the original source code will need to use ASM to remove the
method body. Most software that utilised SM has been written with SM
as a configuration concern, it could either run with SM or without if
it was null. This SecurityException is unexpected when SM is not set.
The changes in this JEP should have zero impact on the vast majority
of deployments. It was very rare to deploy with a security manager
set. The deprecation, warnings, and disabling by default demonstrated
responsible stewardship and provided developers with many releases and
years, to prepare for the change.
A few libraries were developed so they could work with a security
manager in the rare case where they get used in an environment that
sets a security manager. Aside from warnings at compile-time, and
maybe tests, the impact for the maintainers of these libraries should
be zero, or close to it. The recommended is of course to remove the
use of these terminally deprecated APIs as they will be eventually
removed.
I think your message is about something more niche where a subset of
the security manager APIs are used to create a custom execution
environment but without setting a security manager. In that case, it
would be wrong for the APIs to behave as if the environment is more
secure that it might actually be. So a forced move to change the
behavior of the APIs. As noted, the change to these APIs is called out
in the JEP. The API docs for checkGuard also has a prominent API note
on the historical vs. changed behavior. Specific Permission classes
are deprecated for removal but it might be some time before the
remaining AllPermission, BasicPermission, and Permission get
attention. There may be an argument to deprecate Guard for removal in
advance of this.
-Alan
