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.
--
Regards,
Peter
On 7/04/2026 4:19 pm, Alan Bateman wrote:
On 07/04/2026 01:19, Peter Firmstone wrote:
Previously when a SecurityManager wasn't enabled
Permission::checkGuard didn't throw a SecurityException. The new
behaviour is to throw a SecurityException when SecurityManager is not
enabled. I understand that OpenJDK wishes to expedite the removal of
these methods from existing code, however this method has not been
deprecated and the new behaviour breaks backward compatibility. Code
that runs on Java 8 or 11 containing these methods cannot run
unmodified on Java 26.
See JEP 486 [1], specifically the section starting "A very small
number of libraries use advanced parts of the Security Manager API to
implement a custom execution environment" where it explains that these
methods have had to be changed to "implement an execution environment
that disallows access to all resources".
-Alan
[1] https://openjdk.org/jeps/486
