RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo

Mon Feb 23 09:04:00 UTC 2015

That looks good to me.

/Staffan

> On 20 feb 2015, at 20:39, Jeremy Manson <jeremymanson at google.com> wrote:
> 
> Staffan, would that be acceptable?
> 
> Jeremy
> 
> On Fri, Feb 20, 2015 at 11:22 AM, Martin Buchholz <martinrb at google.com <mailto:martinrb at 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 <jeremymanson at google.com <mailto:jeremymanson at 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.larsen at oracle.com <mailto:staffan.larsen at 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 <jeremymanson at google.com <mailto:jeremymanson at 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.larsen at oracle.com <mailto:staffan.larsen at oracle.com>> wrote:
>> 
>>> On 18 feb 2015, at 00:58, Jeremy Manson <jeremymanson at google.com <mailto:jeremymanson at 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.chung at oracle.com <mailto:mandy.chung at 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.chung at oracle.com <mailto:mandy.chung at 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.chung at oracle.com <mailto:mandy.chung at 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
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150223/851028e9/attachment.html>