Please review a moderately simple change for javadoc, to improve the way
that newlines in user input (doc comments and values for command-line
options) are handled, reducing the amount of overall string copying.
The underlying issue is that user newlines may be \n, \r or \r\n, but
the generated files should only contain \n.
Instead of using Utils.normalizeNewlines (which does an unconditional
copy) at a number of sites, the normalization is now done in
StringContent and RawHtml. In the case of StringContent, the
normalization is done while checking and handling the escape sequences
for < > &; in the case of RawHtml, it is done when constructing the
object, but only if the argument contains \r.
There are no good pre-existing tests for testing newline behavior, and
so a new test is provided that runs javadoc on input containing the
different kinds of newline. The test revealed a previously unknown bug,
that non-standard newslines in command-line option values were not
handled correctly.
The output is also the same (before-and-after) for the generated JDK API
docs.
-- Jon
JBS: https://bugs.openjdk.java.net/browse/JDK-8236048
Webrev: http://cr.openjdk.java.net/~jjg/8236048/webrev.00/index.html
