That looks good to me. /Staffan
> On 20 feb 2015, at 20:39, Jeremy Manson <jeremyman...@google.com> wrote: > > Staffan, would that be acceptable? > > Jeremy > > On Fri, Feb 20, 2015 at 11:22 AM, Martin Buchholz <marti...@google.com > <mailto:marti...@google.com>> wrote: > In jsr166 we rarely use @see, regarding it as a vestige of a time when @link > and @linkplain were not available. Just work a @linkplain into the javadoc. > E.g. > > + /** > + * Returns the {@linkplain Thread#priority() thread priority} of the > thread associated with this > + * {@code ThreadInfo}. > + * > + * @return The priority of the thread associated with this > + * {@code ThreadInfo}. > + * @since 1.9 > + */ > + public int getPriority() { > > > On Fri, Feb 20, 2015 at 10:34 AM, Jeremy Manson <jeremyman...@google.com > <mailto:jeremyman...@google.com>> wrote: > Okay. Thanks for doing this, Staffan. I do have a "@see Thread#getPriority" > there already. Can I just add "This is an integer between {@linkplain > Thread#MIN_PRIORITY} and {@linkplain Thread#MAX_PRIORITY}, inclusive." to the > getPriority javadoc? > > Jeremy > > On Fri, Feb 20, 2015 at 4:10 AM, Staffan Larsen <staffan.lar...@oracle.com > <mailto:staffan.lar...@oracle.com>> wrote: > The CCC request was approved for this change, but there were a couple of > comments: > > 1) "First, syntactically for the javadoc please use "{@code foo}" rather than > "<tt>foo</tt>”.” > > I think you have covered this. > > 2) "You may want to say a bit more about the possible return values of > ThreadInfo.getPriority. For example, are they bound to be within the range > java.lang.Thread.{MIN_PRIORITY, MAX_PRIORITY}?” > > I think this would be good to cover, either by explicitly stating it or by > linking to Thread.getPriorty(). > > 3) "Are there any other getFoo or isFoo methods from java.lang.Thread that > should be replicated in ThreadInfo?” > > The only other method that makes sense is getThreadGroup(), but I don’t think > we need to cover this here. JDK-8023908 has been filed a while back for that. > > Thanks, > /Staffan > >> On 18 feb 2015, at 20:10, Jeremy Manson <jeremyman...@google.com >> <mailto:jeremyman...@google.com>> wrote: >> >> Done. >> >> http://cr.openjdk.java.net/~jmanson/6588467/webrev.02/ >> <http://cr.openjdk.java.net/~jmanson/6588467/webrev.02/> >> >> Jeremy >> >> >> On Wed, Feb 18, 2015 at 1:49 AM, Staffan Larsen <staffan.lar...@oracle.com >> <mailto:staffan.lar...@oracle.com>> wrote: >> >>> On 18 feb 2015, at 00:58, Jeremy Manson <jeremyman...@google.com >>> <mailto:jeremyman...@google.com>> wrote: >>> >>> Since this is not my code, I will happily defer to the people whose code it >>> is on these matters. I can very easily replace all of the <tt> instances, >>> or just the new ones, or none at all. Just let me know. >> >> I would be grateful if you took the time to convert all of them, but I will >> also understand if you don’t want to. >> >>> >>> (My general preference in my own code is to separate feature changes and >>> cleanup changes, just so that the history is more comprehensible, but I can >>> certainly understand that you might not want to go that way when the cost >>> of a checkin is so high.) >> >> Agree that cost of checkin is high… >> >> /Staffan >> >>> >>> Jeremy >>> >>> On Tue, Feb 17, 2015 at 3:55 PM, Mandy Chung <mandy.ch...@oracle.com >>> <mailto:mandy.ch...@oracle.com>> wrote: >>> On 2/17/15 3:10 PM, Martin Buchholz wrote: >>>> I don't think feature changes should be mixed with maintenance. >>>> >>>> Code janitor is the most honourable profession, and it would be awesome >>>> for a code janitor to convert the entire jdk to {@code but feature >>>> contributors should not be asked to do so. >>> >>> That's why I didn't ask at first :) >>> >>> I prefer the new javadoc to use {@code...} even though inconsistent with >>> other methods as they were defined since 1.5. >>> >>> Mandy >>>> >>>> On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung <mandy.ch...@oracle.com >>>> <mailto:mandy.ch...@oracle.com>> wrote: >>>> On 2/17/15 9:31 AM, Jeremy Manson wrote: >>>>> Hey Mandy, >>>>> >>>>> Thanks for taking a look. Are we okay making those changes even though >>>>> none of the other methods in ThreadInfo follow those conventions? Not >>>>> sure whether consistency matters more or less than doing it right. >>>> >>>> I wont object and actually be grateful if you want to convert all >>>> <tt>...</tt> to {@code ...}. Staffan may have a different opinion. >>>> >>>> Mandy >>>>> >>>>> Jeremy >>>>> >>>>> On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung <mandy.ch...@oracle.com >>>>> <mailto:mandy.ch...@oracle.com>> wrote: >>>>> Hi Jeremy, >>>>> >>>>> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >>>>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ >>>>> <http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.01/><http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.01/ >>>>> <http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.01/>> >>>>> >>>>> >>>>> The change looks okay to me. >>>>> >>>>> Nit: It would be good for the new methods to replace <tt>...</tt> with >>>>> {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to add >>>>> {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . >>>>> Similarly Thread#getPriority. >>>>> >>>>> thanks >>>>> Mandy >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > > >
