Am 02.09.2009 18:27, Martin Buchholz schrieb:
On Wed, Sep 2, 2009 at 01:07, Ulf Zibis <ulf.zi...@gmx.de
<mailto:ulf.zi...@gmx.de>> wrote:
Am 02.09.2009 05:21, Martin Buchholz schrieb:
/**
- * The minimum value of a Unicode surrogate code unit in the
UTF-16 encoding.
+ * The minimum value of a Unicode surrogate code unit in the
+ * UTF-16 encoding, constant <code>'\uD800'</code>.
*
* @since 1.5
*/
public static final char MIN_SURROGATE = MIN_HIGH_SURROGATE;
I would have used {...@code here if I could figure out
how to make it work
("\" shows up literally in the generated output).
Could this be seen as a bug? IMHO the {...@code construct should be a 100%
replaceable for <code>. Any Bug Id ?
A brave person such as yourself could try to
become "code janitor" for the whole jdk.
In this case it should be simple to replace <code>...</code>
against {...@code ...} on the whole JDK. My problem is, that I don't
have the CPU-power to build the JDK, and check the whole javadoc
if it would have broken.
Building the javadoc requires a lot of memory -
a javadoc bug - someone could try to fix that...
... but as we see, simply replacing <code>...</code> against {...@code ...}
in the whole JDK would not work. :-(
Yes, after a closer look I can see the point, so I corrected their
usage where I thought, it was wrong.
But what's about using {...@code U+10000}, found for
MIN_SUPPLEMENTARY_CODE_POINT javadoc ?
"U+10000" is not valid java code, but I must admit, that it looks
better than "0x010000"
Maybe we must use <tt>U+10000</tt> here.
No answer. Does that mean, {...@code U+10000} is valid?
- I would like to see backwards-referring like: public static final
int MIN_CODE_POINT = MIN_VALUE;
public static final int MIN_SUPPLEMENTARY_CODE_POINT =
MAX_VALUE + 1;
Those would work, but would add to the confusion
between code points and UTF-16 code units.
Notice how "MAX_VALUE + 1" looks like an oxymoron.
;-)
But I don't have any problem as I don't have using Byte.MAX_VALUE + 1.
The real source of the confusion is elsewhere, i.e. imagine we
would have class Integer managing 16 + 32 bit values.
Maybe it would become more clear adding
MAX_SUPPLEMENTARY_CODE_POINT for *consistency* and having
following order:
MAX_SUPPLEMENTARY_CODE_POINT would not be a bad thing to have,
but not compelling enough for the effort involved with any change to
java se.
:-(
... but changing the order would decrease the confusion ?
-Ulf
