Miscellaneous minor patches: javadoc typos, javac warnings, etc.

[Xiomara Jayasena]

Hello Martin,

The contribution process for JDK6 and JDK7 is described here:
http://openjdk.java.net/contribute/

Most likely JDK8 will follow a very similar process if not the exact one described there.

Regards,
-Xiomara


-----Original Message-----
From: Martin Desruisseaux [mailto:martin.desruisseaux at geomatys.fr] 
Sent: Tuesday, October 04, 2011 9:18 AM
To: jdk8-dev at openjdk.java.net
Subject: Miscellaneous minor patches: javadoc typos, javac warnings, etc.

Hello all

I have a set of minor patches that I would like to submit for JDK8. I'm not yet familiar with the contribution process. I presume that sending patches by email is not the preferred way, but I'm not sure which process I should use.

  * JavadocTypos.patch contains only minor typo fixes in javadoc comments. Note
    that the fix inside the {@code} element is because javadoc renders >
    verbatism - no HTML entity is expected inside {@code}.
  * JavacWarnings.patch fixes a few javac warnings, most of them related to
    generic types.
  * ReuseExistingMethods.patch replaces calls to Math.sqrt(x*x + y*y) by
    Math.hypot(x, y) - with the benefit of better protection against floating
    point overflow - and reuse existing constructors instead than passing 0
    values in argument.
  * AvoidStringConcatenation.patch replaces calls to "" + x by String.valueOf(x)
    in order to avoid useless objects creation caused by string concatenation
    (unless javac was clever enough to detect that the string concatenation was
    useless, which I don't know).
  * UselessInstantiation.patch avoid a useless object creation, since the
    BufferedImage constructor explicitely accepts (stated in the javadoc) null
    Hashtable if there is no properties.
  * InnerClasses.patch declares some private inner classes as static, which
    avoid a useless reference to the enclosing class. If only one patch was to
    be applied, I would like to be that one. Some complex image formats may have
    thousands of IIOMetadataNode, and I'm afraid that the cost of thousands of
    useless references to the enclosing IIOMetadataFormatImpl may be significant.


Regards,

     Martin