8016217: More javadoc warnings
Joe Darcy
joe.darcy at oracle.com
Tue Jun 11 16:34:03 UTC 2013
On 6/11/2013 5:33 AM, Alan Bateman wrote:
> On 11/06/2013 13:08, Sean Mullan wrote:
>> The changes to classes in the security component look fine. One
>> question I have is about the change to
>> javax/xml/crypto/dsig/Manifest.java. Was there a specific error here
>> or did you just want to make this cleaner by removing all of the html
>> special character handling? The reason I ask is that there are many
>> other classes in javax.xml.crypto which have similar javadoc
>> sections, so I am wondering if they have similar issues.
> The error was at line 41:
>
> * <sequence>
>
> The > should have been >
>
> There are several other examples of the same thing. Also there are
> several cases (in other areas) where there was an attempt to use <
> or > but the semicolon was left out.
>
> So for this case then I could have fixed it by using > but since
> this is XML schema definition then I personally think it's a lot more
> readable to have the original XML in {@code ...}. Another example is
> the DTD in java/util/Preferences.java where the error was a missing
> semi-colon, in that case it seems more readable (to me anyway) to have
> the DTD passed in. Same thing for code examples that have type
> parameters. As I mentioned in one of the mails yesterday (and I think
> Mike's mail is agreeing) it is very tempting to replace all
> <code></code> usages with {@code ...}. This would require un-doing
> existing escaping but the result should be more readable and less
> error-pone when edited.
I would support (and even help review!) a bulk change of
<code>foo</code> to {@code foo}. Whenever I look at <code>foo</code>, my
eyes hurt. IIRC, there are a few cases which require HTML escaping, like
trying to output a fixed-width "@" character, but they are a very small
minority.
-Joe
More information about the core-libs-dev
mailing list