RFR: jsr166 openjdk9 integration

Martin Buchholz martinrb at google.com
Wed Sep 23 19:33:47 UTC 2015

On Wed, Sep 23, 2015 at 3:16 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
> 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:
>   ConcurrentLinkedDeque
>   CopyOnWriteArraySet
>   ScheduledExecutorService
>   ScheduledThreadPoolExecutor
>   LockSupport
>   ReentrantReadWriteLock
> Any opinions? sometimes it’s a fine line between a clarification and a
> spec update.
Right. jsr166 bulk updates generally contain so many diverse changes that I
always just assume a CCC would be required (in the past, this was done via
a single request instead of split up as we are doing here).

If you generate a public specdiff (as I believe only Oracle folks can), it
would be easier for all of us to review the spec changes.

> There are some new methods we need to track in the following classes:
>   LinkedTransferQueue
>   SynchronousQueue
Those aren't "really" new methods - just new drop-in implementations of
existing interface methods like toString(), with no new real spec content.
But yeah, a grey area.

> 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?
Compare and contrast:

This is a workaround for
javadoc should not use a monotype font for <dd> elements

> 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.

Of course, this is "just" a (relatively unimportant) performance
Should only classes in java.lang get to use the constructor  String(char[]
value, boolean share)?
Will there be a jigsaw-blessed way of creating Strings this way from
"trusted" modules?
More generally, will there be a blessed way to provide relatively unsafe
access to code you trust?
Will hotspot be smart enough to elide the allocation by proving the input
array is never used again?

More information about the core-libs-dev mailing list