Re: RFR 8217339: ClassCircularityError loading NumberFormatProvider

2019-01-23 Thread Naoto Sato

+1

Naoto

On 1/22/19 3:25 PM, Mandy Chung wrote:



On 1/22/19 2:25 PM, Roger Riggs wrote:

Hi Mandy,

Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-2/




Looks good.



Other changes look good.

BTW,

> I have not found a reproducer for jdk 12, it only occurs on new 
work for

> jdk 13.

Is this new code in 13? l10n causes this type of circularity 
exception during the VM boot up.




I also want to understand what changes in 13 causes the difference.

I was prototyping some more properties ideas.
I suspect that in the previous init sequence, the Locale had been cached.
A closed test had failed, in part because it had changed the default 
locale

and then installed a security manager.


I see how ConstantDesc gets initialized during initialization of 
VarHandle from
your stack trace.  I can't reproduce it and so I assume it was triggered 
by your
local change.  In any case, converting String.format to string concat is 
fine.


I am sure Claes may look at the startup and class initialization if we 
can avoid

loading VarHandleDesc from clinit.

Mandy



Re: RFR 8217339: ClassCircularityError loading NumberFormatProvider

2019-01-22 Thread Mandy Chung




On 1/22/19 2:25 PM, Roger Riggs wrote:

Hi Mandy,

Updated webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-2/




Looks good.



Other changes look good.

BTW,

> I have not found a reproducer for jdk 12, it only occurs on new 
work for

> jdk 13.

Is this new code in 13? l10n causes this type of circularity 
exception during the VM boot up.




I also want to understand what changes in 13 causes the difference.

I was prototyping some more properties ideas.
I suspect that in the previous init sequence, the Locale had been cached.
A closed test had failed, in part because it had changed the default 
locale

and then installed a security manager.


I see how ConstantDesc gets initialized during initialization of 
VarHandle from
your stack trace.  I can't reproduce it and so I assume it was triggered 
by your
local change.  In any case, converting String.format to string concat is 
fine.


I am sure Claes may look at the startup and class initialization if we 
can avoid

loading VarHandleDesc from clinit.

Mandy



Re: RFR 8217339: ClassCircularityError loading NumberFormatProvider

2019-01-22 Thread Roger Riggs

Hi Mandy,

Updated webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-2/

On 1/22/19 3:47 PM, Mandy Chung wrote:



On 1/22/19 12:29 PM, Naoto Sato wrote:

Hi Roger,

I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(), 
which is the language invariant locale.




Alternatively, convert those String.format to string concatenation and 
they

are pretty simple format only one argument.

ok,



Other changes look good.

BTW,

> I have not found a reproducer for jdk 12, it only occurs on new 
work for

> jdk 13.

Is this new code in 13? l10n causes this type of circularity 
exception during the VM boot up.




I also want to understand what changes in 13 causes the difference.

I was prototyping some more properties ideas.
I suspect that in the previous init sequence, the Locale had been cached.
A closed test had failed, in part because it had changed the default locale
and then installed a security manager.


Is there a regression test?


My test class is:
public class Circ {
    public static void main(String[] args) {
    Locale.setDefault(Locale.ENGLISH);
    System.setSecurityManager(new SecurityManager());

    NumberFormat nf = NumberFormat.getInstance();
    }
}

The circularity error only occurred if the default locale was changed.

But I was unable to reproduce it without other changes.

Thanks, Roger


Mandy


Naoto

On 1/22/19 12:08 PM, Roger Riggs wrote:
A ClassCircularityError can occur via the ClassDescriptor code that 
uses String.format to

concatenate strings.

Please review a change to use string concatenation or a known locale 
instead

of the default locale in calls to String.format.

The java.lang.constant APIs can be used early in the startup 
sequence before

the Locales and providers are initialized.

See the bug report for the full stack trace.
https://bugs.openjdk.java.net/browse/JDK-8217339

I have not found a reproducer for jdk 12, it only occurs on new work 
for jdk 13.


Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1

Thanks, Roger







Re: RFR 8217339: ClassCircularityError loading NumberFormatProvider

2019-01-22 Thread Mandy Chung




On 1/22/19 12:29 PM, Naoto Sato wrote:

Hi Roger,

I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(), 
which is the language invariant locale.




Alternatively, convert those String.format to string concatenation and they
are pretty simple format only one argument.


Other changes look good.

BTW,

> I have not found a reproducer for jdk 12, it only occurs on new work 
for

> jdk 13.

Is this new code in 13? l10n causes this type of circularity exception 
during the VM boot up.




I also want to understand what changes in 13 causes the difference.

Is there a regression test?

Mandy


Naoto

On 1/22/19 12:08 PM, Roger Riggs wrote:
A ClassCircularityError can occur via the ClassDescriptor code that 
uses String.format to

concatenate strings.

Please review a change to use string concatenation or a known locale 
instead

of the default locale in calls to String.format.

The java.lang.constant APIs can be used early in the startup sequence 
before

the Locales and providers are initialized.

See the bug report for the full stack trace.
   https://bugs.openjdk.java.net/browse/JDK-8217339

I have not found a reproducer for jdk 12, it only occurs on new work 
for jdk 13.


Webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1

Thanks, Roger





Re: RFR 8217339: ClassCircularityError loading NumberFormatProvider

2019-01-22 Thread Naoto Sato

Hi Roger,

I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(), which 
is the language invariant locale.


Other changes look good.

BTW,

> I have not found a reproducer for jdk 12, it only occurs on new work for
> jdk 13.

Is this new code in 13? l10n causes this type of circularity exception 
during the VM boot up.


Naoto

On 1/22/19 12:08 PM, Roger Riggs wrote:
A ClassCircularityError can occur via the ClassDescriptor code that uses 
String.format to

concatenate strings.

Please review a change to use string concatenation or a known locale 
instead

of the default locale in calls to String.format.

The java.lang.constant APIs can be used early in the startup sequence 
before

the Locales and providers are initialized.

See the bug report for the full stack trace.
   https://bugs.openjdk.java.net/browse/JDK-8217339

I have not found a reproducer for jdk 12, it only occurs on new work for 
jdk 13.


Webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1

Thanks, Roger



RFR 8217339: ClassCircularityError loading NumberFormatProvider

2019-01-22 Thread Roger Riggs
A ClassCircularityError can occur via the ClassDescriptor code that uses 
String.format to

concatenate strings.

Please review a change to use string concatenation or a known locale 
instead

of the default locale in calls to String.format.

The java.lang.constant APIs can be used early in the startup sequence before
the Locales and providers are initialized.

See the bug report for the full stack trace.
  https://bugs.openjdk.java.net/browse/JDK-8217339

I have not found a reproducer for jdk 12, it only occurs on new work for 
jdk 13.


Webrev:
 http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1

Thanks, Roger