RFR: jsr166 openjdk9 integration

[Chris Hegarty]

> On 23 Sep 2015, at 20:33, Martin Buchholz <martinrb at google.com> wrote:
> 
> On Wed, Sep 23, 2015 at 3:16 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto: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).

For 8 we separated out the tasks into several subtasks ( and CCC’s ) as being done here. This worked well, at least from my point of view. See  https://bugs.openjdk.java.net/browse/JDK-8001566 <https://bugs.openjdk.java.net/browse/JDK-8001566>


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

Should not require a CCC then.

> 
>> 
>> 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://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 <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 <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?

-Chris.