jsr166 vs jdk-9+114

[Martin Buchholz]

On Tue, Apr 19, 2016 at 2:40 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 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.

Confirmed.  We're moving to jdk.internal.misc.Unsafe.

(But this is yet another case of java developers scratching their
heads at NoClassDefFoundError where the root cause exception has been
lost; is that really so hard to fix? ...)