hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

[Ulf Zibis]

Am 02.09.2009 18:27, Martin Buchholz schrieb:
>
>
> On Wed, Sep 2, 2009 at 01:07, Ulf Zibis <Ulf.Zibis at gmx.de 
> <mailto:Ulf.Zibis at 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
> ("&#92" 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090902/0eeedd83/attachment.html>