Review Request: 7164376 Replace use of

Mandy Chung mandy.chung at
Thu Apr 26 14:20:56 PDT 2012

Thanks, Sean.  I have fixed the 3 files per your comment.


On 4/26/2012 1:59 PM, Sean Mullan wrote:
> Looks fine, just a couple of nits.
> src/macosx/classes/com/apple/concurrent/,
>   - the closing static brace is not indented the same as the open brace.
> src/solaris/classes/sun/management/
> src/windows/classes/sun/management/
>   - line-break coding style is different from all others; probably 
> better to be consistent
> --Sean
> 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:
>> FROM:
>> 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