jsr166 vs jdk-9+114

[Martin Buchholz]

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'