RFR: regex changes -- sun.security.util.Debug issue

Sean Mullan sean.mullan at oracle.com
Tue May 10 17:23:21 UTC 2016



On 5/10/16 1:30 AM, Alan Bateman wrote:
> On 10/05/2016 06:36, Xueming Shen wrote:
>> Hi,
>>
>> While testing for the attached regex changes, a fatal vm init error
>> was triggered for test
>> case with -Djava.security.debug=xyz turned on, as showed in following
>> stacktrace.
>>
>> It appears sun.security.util.Debug is being initialized even before
>> the lambda is ready
>> for use, and unfortunately it uses j.u.regex (for its args parsing),
>> which is being migrated
>> to use lambda function in the proposed regex change.
>>
>> Since Debug is the only class now triggers j.u.regex -> lambda during
>> initialization, it
>> is suggested to update/rewrite the related method in Debug to NOT use
>> j.u.regex to
>> solve/workaround this specific initialization issue.
> This is always tricky but I wonder how far we could get by initializing
> ProtectionDomain.debug and SecureClassLoader.debug lazily. That is, move
> them to a holder class where I wouldn't expect they will be initialized
> until much later, esp. as the security manager won't be set until later
> in the initialization (or init phase 3 as we've come to name it).

Actually, ProtectionDomain already does something like this. It only 
writes to debug if the policy has been set. See toString():

        PermissionCollection pc = Policy.isSet() && seeAllp() ?
                                       mergePermissions():
                                       getPermissions();

So, a simpler fix is to extend that concept and not initialize the debug 
field until Policy.isSet is true. This should resolve this bootstrapping 
issue.

--Sean



More information about the security-dev mailing list