RFR: 8231186: Replace html tag <code>foo</code> with javadoc tag {@code foo} in java.base

Brent Christian brent.christian at oracle.com
Fri Sep 20 21:02:48 UTC 2019

Hi, Julia

On 9/20/19 3:22 AM, Julia Boes wrote:
> Hi,
> Thanks for noticing the glitch in the sdiffs, Naoto and Brent. I see 
> that there is indeed an issue with the webrev script and I'm looking 
> into a workaround.
> The following classes are affected:
> src/java.base/share/classes/java/lang/SecurityManager.java
> src/java.base/share/classes/java/util/Calendar.java

The Udiffs for these look fine.

> src/java.base/share/classes/java/util/ResourceBundle.java

I believe the <code> tag spanning L2801-2 can be changed:

2801          * <li>Special cases for Norwegian.  Both 
<code>Locale("no", "NO",
2802          * "NY")</code> and {@code Locale("nn", "NO")} represent 

Same at L2818-9:

2818          * Bokmål "nb".  Except for the single case <code>Locale("no",
2819          * "NO", "NY")</code> (handled above), when an input {@code 

> src/java.base/share/classes/java/util/regex/Matcher.java

All I see in this file is the final closing brace being replaced with a 
closing brace :D

>> in PipedInputStream.java:
>>  195      * @exception IOException If the pipe is <a href="#BROKEN"> 
>> {@code broken}</a>,
>> Here we have a link written out in HTML, with {@code} used within the 
>> displayed text of the link.  This would typically be done instead by 
>> using a @link tag, as on the next line:
>>  196      *          {@link #connect(java.io.PipedOutputStream) 
>> unconnected},
>     Brent, I can make this change but can the @link tag link to a HTML
>     id? It's not mentioned in the documentation
> https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#link. 

Oh, I see now - #BROKEN is a hand-coded HTML anchor, not a field name. 

> I recall thinking that many of the <code> should actually be changed 
> to @link since use of <code> suggested ancient times before @link became 
> available.
> But "Perfect is the enemy of good".


>      I agree, if that's ok I would leave that as future work ;)

Definitely OK.  Those may even already be "correct", and not suitable 
uses of @link at all.


More information about the core-libs-dev mailing list