+1
On 5/10/2016 2:57 PM, Xueming Shen wrote:
webrev has been updated as suggested, now the lazily-init-class-holder
is used
to delay the Debug initialization. Tests all passed locally. A jprt
job is out to confirm.
Here is the updated webrev
http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/
Thanks!
Sherman
On 05/10/2016 01: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).
-Alan
