On Wed, Sep 23, 2015 at 3:16 AM, Paul Sandoz <paul.san...@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?
