RFR: jsr166 openjdk9 integration

[Paul Sandoz]

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

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

Yes, Roger also suggested the same to me off list. May happen tomorrow.


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

Ok.


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

Thanks, i changed that issue from an enhancement to a bug. I have also noticed some rendering issues with the @apiNote etc. Ideally i wish we could just fix the javadoc generation rather than having to work around them.


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

Keeping focus, i think the first question to be asked is whether for a particular use-case unsafe String construction is really necessary, and in this case i strongly suspect the answer is no.

Paul.

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