java.security.AccessController deprecated since Java 17 and subject to removal in a future version

[Stephan Bergmann]

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