Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed <code> element

Dan Xu dan.xu at oracle.com
Wed Aug 29 00:13:45 UTC 2012


I will update the change with your suggestion. Thanks!

-Dan



On 08/28/2012 04:52 PM, Ulf Zibis wrote:
> Thanks for your feedback Dan.
>
> But I still think, the link to the javadoc of a class should not be 
> labelled by a variable name.
> So maybe use:
>  212      * Converts the buffer's contents into a string by decoding 
> the bytes using
>  213      * the {@link java.nio.charset.Charset}, specified by it's 
> name. The length of
> or:
>  212      * Converts the buffer's contents into a string by decoding 
> the bytes using
>  213      * the {@link java.nio.charset.Charset}, specified by it's 
> {@code charsetName}.
> And:
>  222      * @param  charsetName  the name of a supported
>  223      *         {@link java.nio.charset.Charset}
>
> -Ulf
>
> Am 29.08.2012 01:39, schrieb Dan Xu:
>> Thanks for your comments, Ulf.
>>
>> I looked at the definitions of @link and @linkplain again. And I find 
>> that this nested situation can be easily avoided by replacing 
>> @linkplain with @link as the following,
>>
>>     {@link java.nio.charset.Charset charset}
>>
>> I will update my changes.
>>
>> -Dan
>>
>>
>>
>> On 08/28/2012 02:20 PM, Ulf Zibis wrote:
>>> Am 28.08.2012 11:45, schrieb Alan Bateman:
>>>> On 27/08/2012 21:48, Dan Xu wrote:
>>>>> This change is to fix the java doc font issue for 
>>>>> ByteArrayOutputStream class. In current javadoc, contents change 
>>>>> to the wrong font starting from toString(String charsetName) in 
>>>>> ByteArrayOutputStream.html, which can be viewed at 
>>>>> http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html.
>>> I think the link to the javadoc of a class should not be labelled by 
>>> a variable name:
>>>  212      * Converts the buffer's contents into a string by decoding 
>>> the bytes using
>>>  213      * the specified {@link java.nio.charset.Charset 
>>> charsetName}. The length of
>>> Maybe better:
>>>  212      * Converts the buffer's contents into a string by decoding 
>>> the bytes using
>>>  213      * the {@link java.nio.charset.Charset}, specified by it's 
>>> name. The length of
>>> or:
>>>  212      * Converts the buffer's contents into a string by decoding 
>>> the bytes using
>>>  213      * the {@link java.nio.charset.Charset}, specified by it's 
>>> [@code charsetName}. The length of
>>> Same for:
>>>  222      * @param  charsetName  the name of a supported
>>>  223      *              {@link(plain) java.nio.charset.Charset}
>>>
>>> Additionally you could align the param items:
>>>  224      * @return  String decoded from the buffer's contents.
>>>  225      * @throws UnsupportedEncodingException
>>>  226      *         If the named charset is not supported
>>>  227      * @since  JDK1.1
>>>
>>>  227      * @since  JDK1.1
>>> Shouldn't it be? :
>>>  227      * @since  1.1
>>>
>>>>> The webrev is at http://cr.openjdk.java.net/~dxu/7193710/webrev/.
>>>> This looks fine me as it doesn't seem you can use @code here (Joe 
>>>> or Jon might be able to say what the rules are for nesting these 
>>>> javadoc tags).
>>> Interesting question, maybe a bug in javadoc?
>>> Maybe {@link ...} instead {@linkplain ...} would work.
>>>
>>> +1 for taking the opportunity to upgrade the file to using {@code}, 
>>> {@link}, <tt>...</tt> to {@code ...} etc., even if in this special 
>>> nested case a trick is needed.
>>>
>>> -Ulf
>>>
>>
>>
>




More information about the core-libs-dev mailing list