Review Request: 7164376 Replace use of

Phil Race philip.race at
Thu Apr 26 15:51:35 PDT 2012

All looks good to me. Compiler won't spot misspelled library names so I
did try to check all those are still the same.


On 4/26/2012 2:20 PM, Mandy Chung wrote:
> Thanks, Sean.  I have fixed the 3 files per your comment.
> Mandy
> 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