RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization

[Sean Mullan]

On 1/12/17 3:53 PM, Mandy Chung wrote:
>
>> On Jan 11, 2017, at 5:34 AM, Adam Petcher <adam.petcher at oracle.com>
>> wrote:
>>
>> Please review the following bug fix:
>>
>> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/
>>
>> This fixes a bug in which a permission check would try to load
>> resources while the system class loader is being initialized.
>> Resources cannot be loaded at this time, so this change ensures
>> that the resources are loaded earlier.
>
> This seems a reasonable approach.  There is a slight overhead for
> this change when the resource bundle is never used but it’s not an
> issue since the initialization of a security manager is not cheap
> anyway.
>
> It may be helpful to add a check to ensure that the resource bundle
> is loaded either VM.isBooted() or initLevel != 3.  It would make it
> clear of this circular bootstrapping issue.
>
> You do this in SecurityManager class initialization.  Have you
> considered doing it in the SecurityManager constructor?  As Claes
> clarified, SM is loaded but not initialized during early VM startup.
> So no issue to do it in clinit.  The alternative is to do it in the
> constructor as lazy initialization.

I don't see any particular performance advantage of moving it to the 
constructor. The SM will be initialized and instantiated in phase 3 
before it initializes the system classloader. Did you have another 
concern in mind?

>
> ResourcesMgr.java Is the doPrivileged necessary?  It’s old code
> written long ago.  Perhaps we should file a bug to clean this up
> later.

At this point in JDK 9, it's probably better to leave it alone until we 
have more time to evaluate it. Adam, please file a bug to look into this 
more, unless you can quickly determine that it is needed.

--Sean