jsr166 vs jdk-9+114

[Remi Forax]

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> À: "Martin Buchholz" <martinrb at google.com>, "jigsaw-dev" <jigsaw-dev at openjdk.java.net>, "Doug Lea" <dl at cs.oswego.edu>
> Envoyé: Mardi 19 Avril 2016 23:40:10
> Objet: Re: jsr166 vs jdk-9+114
> 
> On 19/04/2016 21:45, Martin Buchholz wrote:
> > I tried upgrading my local jdk to jdk-9+114 and jsr166 tests failed with:
> >
> >       [java] Executing '/home/martin/jdk/jdk9/bin/java' with arguments:
> >       [java] '-Xpatch:/home/martin/jsr166/pristine/build/classes'
> >       [java] '-XaddReads:java.base=jdk.unsupported'
> >       [java] '-ea'
> >       [java] '-esa'
> >       [java] '-Djsr166.testImplementationDetails=true'
> >       [java] '-Djsr166.tckTestClass=JSR166TestCase'
> >       [java] '-classpath'
> >       [java]
> >       '/home/martin/jsr166/pristine/lib/junit.jar:/home/martin/jsr166/pristine/build/tck-classes'
> >       [java] 'JSR166TestCase'
> >       [java]
> >       [java] The ' characters around the executable and arguments are
> >       [java] not part of the command.
> >       [java] Error occurred during initialization of VM
> >       [java] java.lang.NoClassDefFoundError: Could not initialize class
> > java.lang.ThreadLocal
> >       [java] at
> >       java.lang.StringCoding.<clinit>(java.base/StringCoding.java:62)
> >       [java] at java.lang.String.<init>(java.base/String.java:587)
> >       [java] at java.lang.String.<init>(java.base/String.java:609)
> >       [java] at java.lang.System.initProperties(java.base/Native Method)
> >       [java] at java.lang.System.initPhase1(java.base/System.java:1850)
> >
> > StringCoding.java:62 is just doing new ThreadLocal<>(); why would that
> > fail?
> > Why doesn't the error include more details on WHY it's failing?
> > Surely ThreadLocal can be found!
> > (this may be a long-standing diagnosability problem with the JDK)
> > I don't see any obvious way to debug this, although I suspect our
> > temporary use of '-XaddReads:java.base=jdk.unsupported'
> The VM can only load an execute in java.base during early startup. In
> this case, it's really early in the initialization of java.lang.System.
> I assume the NoClassDefFoundError is when trying to load
> sun.misc.Unsafe, probably AtomicInteger because ThreadLocal uses it. I
> don't think this is solvable without moving the jsr166 classes to
> jdk.internal.misc.Unsafe.

yes, the issue is that now sun.misc.Unsafe is in jdk.unsupported and not in java.base anymore.

> 
> -Alan
> 
> 
> 

Rémi