8017325, 8017326: Cleanup of javadoc tag (original) (raw)

Jason Uh jason.uh at oracle.com
Wed Jun 26 14:19:12 UTC 2013

Nithya,

Thanks for catching that. I've labeled the bugs with noreg-doc.

Jason

On 6/25/13 9:25 PM, Nithya Srinivasan wrote:

Jason

Can you please add the appropriate noreg- label for the 2 bugs - JDK-8017325 & JDK-8017326 Thanks Nithya On 6/25/2013 1:32 PM, Joe Darcy wrote: Hi Jason,

The javadoc changes look good to go back. Thanks, -Joe On 6/25/2013 1:23 PM, Jason Uh wrote: Joe,

Here are the updated webrevs: - java.security.cert: http://cr.openjdk.java.net/~juh/8017325/webrev.02/ - java.security.spec: http://cr.openjdk.java.net/~juh/8017326/webrev.01/ I have converted "..." to "{@code ...}" and have updated the copyright dates. I've attached diffs of the patches to show what has been updated in these new webrevs. There is a little extra noise in them due to the change in the timestamps. Thanks, Jason

On 06/24/2013 06:11 PM, Joseph Darcy wrote: On 6/24/2013 3:00 PM, Jason Uh wrote:

On 6/24/13 10:51 AM, Joe Darcy wrote: Hi Jason, On 6/21/2013 6:58 PM, Jason Uh wrote: After learning that javadoc is now capable of properly formatting the "

{@code ...}
" construct, I have updated the changeset for java.security.cert. Please review instead: Webrevs -- - java.security.cert (updated): http://cr.openjdk.java.net/~juh/8017325/webrev.01/ - java.security.spec (no change): http://cr.openjdk.java.net/~juh/8017326/webrev.00/ I've looked over both patches and they look fine. However, as a follow-up, please also expand the conversion to include mapping "foo" => "{@code foo}". Thanks. I can make those changes, but are you suggesting that I add them to this changeset or that I do that separately? For review purposes, I'd like to see them separately in some fashion, even if it was produced by diffing the patch files.

Note that this change does visibly change the generated javadoc, as reported by specdiff. In particular, the change to 

{@code
...} in the javadoc for the X509Extension.getNonCriticalExtensionOIDs() method now allows the generated HTML to correctly display the line: Set nonCritSet = badCert.getNonCriticalExtensionOIDs(); which was previously (incorrectly) displayed as Set nonCritSet = badCert.getNonCriticalExtensionOIDs(); when the text "" was still enclosed within "
...
". Running specdiff is a good double-check in this situation. Should the scripts you are using here to placed somewhere in the JDK repo or in the code tools project? I'm not sure that I follow. Are you requesting that I include somewhere in the repo the line of Perl that I ran? (It was used to make most, but not all of these changes.) If so, where would be the most appropriate place to add that? If it is a one-liner, it could be included in the summary line of the commit message or as a comment in the bug. If it is more substantive (since we will be rolling out this change across the JDK libraries), having the command in a known-location would be helpful. Especially, if a check for this pattern is built into future code-quality checks. -Joe Thanks, Jason Thanks, -Joe Thanks, Jason The files that have been updated On 6/21/13 5:47 PM, Jason Uh wrote: Joe, all, Could I please get a review of the following changes? These changesets convert the ... javadoc tags to {@code ...} as part of an overall effort to clean up doclint warnings. Webrevs -- - java.security.cert: http://cr.openjdk.java.net/~juh/8017325/webrev.00/ - java.security.spec: http://cr.openjdk.java.net/~juh/8017326/webrev.00/ specdiff reported no changes in the generated docs. More of these to come. Thanks, Jason

More information about the security-dev mailing list