Am 02.09.2009 05:21, Martin Buchholz schrieb:
On Tue, Sep 1, 2009 at 01:29, Ulf Zibis <ulf.zi...@gmx.de
<mailto:ulf.zi...@gmx.de>> wrote:
{...@code is now the preferred way. I tried to modify the methods I changed,
but didn't try to change the whole file.
You also have added old style, so I asked why you have mixed it:
/**
- * 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;
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.
- you have mixed U+1234 and \u1234 style. Why?
They are different things. U+1234 describes a Unicode character or
codepoint,
while '\u1234' is a char (code unit, not code point).
See Unicode glossary.
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.
- often you use '\' for '\', but not ever (e.g. '\t'). I think
we can use always '\'. There should not be so much developers in
the world who can't decode ISO-8859-1 or UTF-xx.
We try hard to keep source code ASCII. Sorry, the world is adopting
UTF-8,
but the transition is rather slow. Maybe in 10 years we can go UTF-8
everywhere.
I have been fallen into a trap: '\' *is* ASCII, it's '\u005C'. so is
there any reason remaining on '\' ???
- 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:
(Note that I added " of type {...@code int}", similar to description of
MIN_VALUE.)
/**
* The minimum value of a
* <a href="http://www.unicode.org/glossary/#code_point";>
* Unicode code point</a>, constant {...@code U+0000}
* of type {...@code int}.
*
* @since 1.5
*/
public static final int MIN_CODE_POINT = MIN_VALUE;
/**
* The minimum value of a
* <a href="http://www.unicode.org/glossary/#supplementary_code_point";>
* Unicode supplementary code point</a>, constant {...@code U+10000}
* of type {...@code int}.
*
* @since 1.5
*/
public static final int MIN_SUPPLEMENTARY_CODE_POINT = MAX_VALUE + 1;
/**
* The maximum value of a
* <a href="http://www.unicode.org/glossary/#code_point";>
* Unicode code point</a>, constant {...@code U+10FFFF}
* of type {...@code int}.
*
* @since 1.5
*/
public static final int MAX_CODE_POINT = 0X10FFFF;
/**
* The maximum value of a
* <a href="http://www.unicode.org/glossary/#supplementary_code_point";>
* Unicode supplementary code point</a>, constant {...@code U+10FFFF}
* of type {...@code int}.
*
* @since 1.7
*/
public static final int MAX_SUPPLEMENTARY_CODE_POINT = MAX_CODE_POINT;
-Ulf
Martin
-Ulf
Am 01.09.2009 00:11, marti...@google.com
<mailto:marti...@google.com> schrieb:
Changeset: db5d6b4cbc11
Author: martin
Date: 2009-08-31 15:00 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/db5d6b4cbc11
6860431: Character.isSurrogate(char ch)
Summary: Add new method Character.isSurrogate(char ch)
Reviewed-by: sherman, darcy, okutsu
