RFR: jsr166 openjdk9 integration

Paul Sandoz paul.sandoz at oracle.com
Wed Sep 23 10:16:06 UTC 2015


I trawled through the patches and could not find anything obvious that clobbered existing JDK stuff.

In the misc/locks patches there are some classes that might contain spec changes:



Any opinions? sometimes it’s a fine line between a clarification and a spec update.

There are some new methods we need to track in the following classes:


In ThreadPoolExecutor there is style used to declare a set of fonts:

 249  * <dd style="font-family:'DejaVu Sans', Arial, Helvetica, sans-serif">
 250  * This class provides {@code protected} overridable
 251  * {@link #beforeExecute(Thread, Runnable)} and

Is that necessary?

In Helpers:

 121     private static String newStringUnsafe(char[] chars) {
 122         // If porting to a JDK where sun.misc.SharedSecrets is not
 123         // available, modify the code below to simply:
 124         // return new String(chars);
 125         // TODO: Can we do this more portably?
 126         return sun.misc.SharedSecrets.getJavaLangAccess().newStringUnsafe(chars);
 127     }

Yes, you can do this more portably *and* safely by not using it! :-)

Do we really really need to use SharedSecrets? IMO this unsafe dependency should be removed in the JDK patch.


On 21 Sep 2015, at 20:34, Martin Buchholz <martinrb at google.com> wrote:

> This is the long-delayed and long-awaited bulk integration for jdk9 from jsr166 CVS.
> Find webrevs here:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> Sorry about the extreme size and tardiness of this integration.
> As a review convenience, I provided a diff-wbB file that contains all the jsr166 integration changes using "hg diff -wbB" that ignores whitespace changes.
> We will need JPRT+specdiff+CCC from Oracle folks
> All changes are subtasks of:
> https://bugs.openjdk.java.net/browse/JDK-8132960

More information about the core-libs-dev mailing list