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
