jsr166 has been pervasively modified to use VarHandles, but there are some other pending changes (that cannot be cleanly separated from VarHandle conversion). We expect this to be the last feature integration for jdk9. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ We're asking Paul to do most of the review work here, as owner of VarHandles JEP and as Oracle employee. We need approval for API changes in https://bugs.openjdk.java.net/browse/JDK-8157523 Various improvements to ForkJoin/SubmissionPublisher code https://bugs.openjdk.java.net/browse/JDK-8080603 Replace Unsafe with VarHandle in java.util.concurrent classes There is currently a VarHandle bootstrap problem with ThreadLocal/AtomicInteger that causes java/util/Locale/Bug4152725.java to fail. Again I'm hoping that Paul will figure out what to do. In the past rearranging the order of operations in <clinit> has worked for similar problems. It's not surprising we have problems, since j.u.c. needs VarHandles initialized to do work, and j.l.invoke needs j.u.c. (notably AtomicInteger and ConcurrentHashMap) to do work. Maybe we need some very low-level concurrency infrastructure that does not use VarHandles, only for bootstrap?