On 23 Sep 2015, at 21:33, Martin Buchholz <marti...@google.com> wrote:
>
>
> 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.
>
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?
>
