The fix look OK for me too.
SAM
On 04.12.2013 18:45, Alexander Scherbatiy wrote:
The fix looks good for me.
Thanks,
Alexandr.
On 12/4/2013 6:24 PM, Yuri Nesterenko wrote:
Colleagues,
Please review another version of the fix.
Here's the webrev:
http://cr.openjdk.java.net/~yan/8029264/webrev.01
Bug is:
https://bugs.openjdk.java.net/browse/JDK-8029264
Here, @code changed to @literal
in certain places and < and > changed (in my changes but not
elsewhere) to {@literal <} and {@literal >} corresp.
I didn't change ≥ and ≤ though: I swear they look much better
than @literal variants, and even easier to read.
Thanks,
-yan
On 12/04/2013 04:47 PM, Alexander Scherbatiy wrote:
There is the definition of the JDK 1.5 tags:
http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/whatsnew-1.5.0.html#tags
The {@literal} tag denotes literal text. The enclosed text is
interpreted as not containing HTML markup or nested javadoc tags. For
example, the doc comment text: {@literal a<B>c}
displays in the generated HTML page unchanged: a<B>c -- that is,
the <B> is not interpreted as bold.
The {@code} tag formats literal text in the code font. It is
equivalent to <code>{@literal}</code>.
JOptionPane.java
- * centered on the screen (depending on the L&F).
+ * centered on the screen (depending on the {@code L&F}).
It seems that it is better to use the literal tag here.
RowFilter.java
- * columns are < 0.
+ * columns are < 0.
The literal tag can be used here also.
Thanks,
Alexandr.
On 12/4/2013 11:47 AM, Yuri Nesterenko wrote:
One more time! Please take a look.
Mailing list is a lousy tool for review requests like this.
Thanks,
-yan
On 12/02/2013 06:07 PM, Yuri Nesterenko wrote:
Colleagues,
please review this yet another cleanup request.
They will never end but then again, they are easy to review.
Here's the webrev:
http://cr.openjdk.java.net/~yan/8029264/webrev.00
Bug is:
https://bugs.openjdk.java.net/browse/JDK-8029264
My routine was:
increase number of allowed warnings/errors; enable doclint.
make all docs > log 2>&1
Pick up swing files to clean.
Clean, running DocLint on them repeatedly, until I only have
unfixable
(for now) issues.
make all docs > log 2>&1
Pick up swing HTML files related to my original list,
run tidy -e on them.
Repeat the cleanup.
As a result, no real code, animal, or plant was harmed.
Some doc issues were eliminated.
Tidy is happy with resulting HTML; the only doclint criteria
still violated require CCC or convention changes.
If you are interested in checking doclint output, try
$JAVA_HOME/bin/java -cp $JAVA_HOME/lib/tools.jar \
com.sun.tools.doclint.DocLint -Xmsgs:all Whatever.java
Thanks,
-yan
