Review Request: 7164376 Replace use of

Sean Mullan sean.mullan at
Thu Apr 26 13:59:41 PDT 2012

Looks fine, just a couple of nits.


   - the closing static brace is not indented the same as the open brace.


   - line-break coding style is different from all others; probably 
better to be consistent


On 04/26/2012 02:49 PM, Mandy Chung wrote:
> 7164376 Replace use of with
> direct call of System.loadLibrary
> Webrev:
> This change is required for jdk modularization. High level summary:
> it replaces the use of LoadLibraryAction:
> LoadLibraryAction("net"));
> TO: AccessController.doPrivileged( new
><Void>() { public Void run() {
> System.loadLibrary("net"); 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
> convenient class that will load
> the system library as a privileged action:
> 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
> 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 lives.
> For example, the management module is trying to load
> Calling the following will fail to find
> 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 class
> to avoid regression.
> Thanks Mandy

More information about the security-dev mailing list