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

[Staffan Larsen]

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/ <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/20150220/a5159456/attachment.html>