8016217: More javadoc warnings

[Iris Clark]

Hi, Alan.

The changes look good to me.

One thing caught my eye.  In java.util.Calendar, around lines 2681 and later around 2702 you removed the "<blockquote>"
 
--- old/src/share/classes/java/util/Calendar.java	2013-06-10 10:37:52.585879060 +0100
+++ new/src/share/classes/java/util/Calendar.java	2013-06-10 10:37:52.297879063 +0100
@@ -2681,9 +2681,9 @@
      * Returns whether this <code>Calendar</code> represents a time
      * before the time represented by the specified
      * <code>Object</code>. This method is equivalent to:
-     * <pre><blockquote>
+     * <pre>{@code
      *         compareTo(when) < 0
-     * </blockquote></pre>
+     * }</pre>
      * if and only if <code>when</code> is a <code>Calendar</code>
      * instance. Otherwise, the method returns <code>false</code>.
      *

But you left them in java.io.Console, javax.security.sasl.SasClient, etc.

--- old/src/share/classes/java/io/Console.java	2013-06-10 10:37:17.361879868 +0100
+++ new/src/share/classes/java/io/Console.java	2013-06-10 10:37:17.093879874 +0100
@@ -75,7 +75,7 @@
  * manually zero the returned character array after processing to minimize the
  * lifetime of sensitive data in memory.
  *
- * <blockquote><pre>
+ * <blockquote><pre>{@code
  * Console cons;
  * char[] passwd;
  * if ((cons = System.console()) != null &&
@@ -83,7 +83,7 @@
  *     ...
  *     java.util.Arrays.fill(passwd, ' ');
  * }
- * </pre></blockquote>
+ * }</pre></blockquote>
  *
  * @author  Xueming Shen
  * @since   1.6

Was the removal intentional?

Thanks,
iris

-----Original Message-----
From: Alan Bateman 
Sent: Monday, June 10, 2013 3:32 AM
To: core-libs-dev
Subject: 8016217: More javadoc warnings


About 8 months ago I tried an early build of doclint [1] and used it to fix up a bunch issues at the time [2]. It's been awhile, so I decided to try out the latest version to see how it has progressed. All I can say is "Yikes".  The good news is that they reported against the original source and that makes it easy when compared to tools that validate the generated html.

I decided to fix up a few issues, mostly syntax (escaping of > and < in
particular) and a few reference issues that were missed the last time (or are new). There are thousands of other issues for anyone that wants to jump in.

I've put the webrev with the changes here:

http://cr.openjdk.java.net/~alanb/8016217/webrev/

In total this fixes ~500 issues, although 270 of those were coming from java.sql.DatabaseMetaData due to the number of un-escaped usages of "=>". In many cases, the changes are simply to use {@code ..} or replace <code> with {@code ...}. It is tempting to just do a global replace on existing <code></code> usages (would fixing up content that is escaped of course).

I've run specdiff on the before & after to check that I didn't mess anything up. One obvious difference is that code examples that use generics now have the type parameters going through to the generated javadoc.

The webrev touches many areas but as the changes are trivial, I don't need a reviewer from every area.

-Alan.

[1] http://openjdk.java.net/jeps/172
[2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39cbe256c3d1