On 14/11/2022 18:54, Julien Nabet wrote:
During a build, I noticed some warning about deprecation of
AccessController.
git grep -n 'java.security.AccessController' gives:
odk/source/com/sun/star/lib/loader/Loader.java:36:import
java.security.AccessController;
ridljar/source/unoloader/com/sun/star/lib/unoloader/UnoLoader.java:25:import java.security.AccessController;
scripting/java/com/sun/star/script/framework/provider/ClassLoaderFactory.java:26:import java.security.AccessController;
xmerge/source/xmerge/java/org/openoffice/xmerge/util/registry/ConverterInfo.java:24:import java.security.AccessController;
source:
https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/security/AccessController.html
For the moment, it's just deprecated but don't know if it's quick/easy
to remove or this must be analyzed.
We only use java.security.AccessController to wrap creation of class
loaders in AccessController::doPrivileged. Which is the common idiom
for class loader construction, to avoid unnecessary SecurityExceptions
when "a security manager exists and its checkCreateClassLoader method
doesn't allow creation of a new class loader"
(<https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/ClassLoader.html#%3Cinit%3E()>)
and the relevant code doesn't yet run with all the privileges it could
run with.
This should still be relevant when running LO against older JRE
installations that might employ such restrictive security managers.
There is no replacement for AccessCotnroller::doPrivileged, and a way
forward is apparently sill being paved. See
<https://openjdk.org/jeps/411> "JEP 411: Deprecate the Security Manager
for Removal":
"In feature releases after Java 18, we will degrade other Security
Manager APIs so that they remain in place but with limited or no
functionality. For example, we may revise
AccessController::doPrivileged simply to run the given action, or revise
System::getSecurityManager always to return null. This will allow
libraries that support the Security Manager and were compiled against
previous Java releases to continue to work without change or even
recompilation. We expect to remove the APIs once the compatibility risk
of doing so declines to an acceptable level."
