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

[Jeremy Manson]

Okey-doke:

http://cr.openjdk.java.net/~jmanson/6588467/webrev.03/

On Mon, Feb 23, 2015 at 1:04 AM, Staffan Larsen <staffan.larsen at oracle.com>
wrote:

> 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>
> 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>
>> 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> 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>
>>>> wrote:
>>>>
>>>> Done.
>>>>
>>>> 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> wrote:
>>>>
>>>>>
>>>>> On 18 feb 2015, at 00:58, Jeremy Manson <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>
>>>>> 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>
>>>>>> 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
>>>>>>> > 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/>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> 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/ed7ccc59/attachment.html>