RFR: jsr166 openjdk9 integration

[Martin Buchholz]

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:
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/ThreadPoolExecutor.html
http://download.java.net/jdk9/docs/api/java/util/concurrent/ThreadPoolExecutor.html

This is a workaround for
https://bugs.openjdk.java.net/browse/JDK-8136434
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
optimization.
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?