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