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