<AWT Dev> Review Request: 7164376 Replace use of sun.security.action.LoadLibraryAction

Mandy Chung mandy.chung at oracle.com
Thu Apr 26 11:49:51 PDT 2012

7164376 Replace use of sun.security.action.LoadLibraryAction
         with direct call of System.loadLibrary


This change is required for jdk modularization. High level summary:
it replaces the use of LoadLibraryAction:

    java.security.AccessController.doPrivileged(new LoadLibraryAction("net"));

        new java.security.PrivilegedAction<Void>() {
            public Void run() {
                return null;

It touches files in awt, security and serviceability area (cc'ed).
For this type of simple change, I think 1-2 reviewers can
review all files (simpler to review jdk.patch) and no need
for all teams to do the reviews.

System.loadLibrary and Runtime.loadLibrary loads a system library of the given
library name that requires RuntimePermission("loadLibrary."+lib) permission.
Many places in the JDK code loading a system native library is using the sun.security.action.LoadLibraryAction convenient class that will load the
system library as a privileged action:
    java.security.AccessController.doPrivileged(new LoadLibraryAction("net"));

The search path of native libraries are coupled with an associated class loader.
For example, the application class loader uses the path specified in the
"java.library.path" system property for native library lookup.  The loadLibrary
implementation uses the caller's class loader for finding the native library being
requested.  For system libraries, the class loader is null and the system library
lookup is handled as a special case. When the sun.security.action.LoadLibraryAction
class is used that is the caller of System.loadLibrary, the caller's class loader
in this case is "null" loader and thus it always finds the native library from
the system library path.

In a modular world, JDK modules may be loaded by multiple different module class
loader.  The following code would not work if it is expected to load a native
library from a module which is not the module where the
sun.security.action.LoadLibraryAction lives.

For example, the management module is trying to load libmanagement.so.  Calling
the following will fail to find libmanagement.so because the caller of
System.loadLibrary is the LoadLibraryAction which is in the base module
and search the library from the base module only. To prepare for jdk
modularization, the use of LoadLibraryAction should be replaced with
a direct call of System.loadLibrary.

This patch also removes sun.security.action.LoadLibraryAction
class to avoid regression.


More information about the awt-dev mailing list