That is code points 0-0x10ffff less 0xd800-0xdfff (which are used as
surrogate pairs to create the post-16-bit values).

The quoted article doesn't show how to iterate over code points of a
String, which goes something like:

    final int num = str.length();
    for (int off=0; off<num; ) {
        int codePoint = str.codePointAt(off);
        ...
        off += Character.charCount(codePoint);
    }

What a mess.

You call it CONSTANT TIME; I call it ORDER OF MAGNITUDE.

For the typical case of US ASCII characters, the BitSet method will be
contained within a mere 16 bytes or so of data. BitSet wins hands down
there.

In the worst case scenario, all characters appear. BitSet will expand to
actively use around 136 K. A HashSet will be using, say 50 MB. One of
these approaches will be more cache-friendly.

In some ways it is similar to the ArrayList vs LinkedList trade-off.

Where HashSet may win is for very short strings with the odd high code
point, particularly if the BitSet is not kept.

Tom Hawtin

On Fri, 25 Nov 2005 19:40:29 -0600, Alan Krueger
<wgzkid502@sneakemail.com> wrote, quoted or indirectly quoted someone
who said :

Here is my new understanding of codepoints.  I was under the delusion
the 32-bit stuff had no effect on ordinary String and char[]

See http://mindprod.com/jgloss/codepoint.html for the formatted
version:

Please speak now, and at any time in future you notice an error:

Unicode started out as a 16-bit code with 64K possible characters. At
first, this seemed more than enough to encode all the world's
alphabets. Unicode was such a success, scholars also soon wanted to
encode dead scripts such as cuneiform as well, and soon all the slots
were full.

Unicode was extended to 32 bits, with the corresponding UTF-16
encoding also extended with a clumsy system of surrogate characters to
encode the 32-bit characters above 0xffff.

The term codepoint in Java tends to be used to mean a slot in the
32-bit Unicode assignment, though I suspect the term is also valid to
mean a spot in Unicode-16 or any other character set.

Java now straddles the 16-bit and 32-bit worlds. You might think Java
would now have a 32-bit analog to Character, perhaps called CodePoint,
and a 32-bit analog to String, perhaps called CodePoints, but it does
not. Instead, Strings and char[] are permitted to contain surrogate
pairs which encode a single high-32-bit codepoint.

StringBuilder.append( int codepoint ) will accept 32-bit codepoints to
append.

FontMetrics.charWidth( int codepoint ) will tell you the width in
pixels to render a given codepoint.

Character.isValidCodePoint( int codepoint ) will tell you if there is
a glyph assigned to that codepoint. That is still no guarantee your
Font will render it though. Character. codePointAt and codePointBefore
let you deal with 32-bit codepoints encoded as surrogate pairs in char
arrays. Most of the Character methods now have a version that accepts
an int codepoint such as toLowerCase.