From: Arcane Jill
> I would be very surprised if it did, since Java chars are still only
> sixteen bits wide,
Yes but they include surrogates as valid values for char, so UTF-16 could be
used to represent variable names. The main problem is not with variables,
member variables and methods, but with class and package names which need to
be mappable into filenames to be stored in a local filesystem (at compile
time) or in a zip directory entry (for packaged applications). Not all
characters are usable as valid filenames, due to the way filesystems may
rearrange or normalize or transcode these names.
> and the new math alphanumerics are not in BMP. Still, I'd be very happy to
be proved wrong on this one.
For now the JLS
(http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html)
defines the language lexical translation as supporting only Unicode 2.1
(every thing else must use "Unicode escapes", notably for characters out of
the BMP which need to be represented as "\uD8xx\uDCxx" and can then only be
used within String constants.)
In section 3.8 -- Indentifiers --, you'll find this:
[quote]
An identifier is an unlimited-length sequence of Java letters and Java
digits, the first of which must be a Java letter. An identifier cannot have
the same spelling (Unicode character sequence) as a keyword (§3.9), boolean
literal (§3.10.3), or the null literal (§3.10.7).
Letters and digits may be drawn from the entire Unicode character set, which
supports most writing scripts in use in the world today, including the large
sets for Chinese, Japanese, and Korean. This allows programmers to use
identifiers in their programs that are written in their native languages.
A "Java letter" is a character for which the method
Character.isJavaIdentifierStart returns true. A "Java letter-or-digit" is a
character for which the method Character.isJavaIdentifierPart returns true.
[/quote]
As the valid characters usable in identifiers need to be mappable into a
Character instance (which only supports UCS2 code points) so that
Character.isJavaIdentifier() can return true, including characters out of
BMP in identifiers would require that surrogates are included in the list of
possible Character instances whose isJavaIndetifier() test returns true.
So let's see the Character class documentation:
[quote]
isJavaIdentifierPart
public static boolean isJavaIdentifierPart(char ch)
Determines if the specified character may be part of a Java identifier as
other than the first character.
A character may be part of a Java identifier if any of the following are
true:
* it is a letter (matches the general categories UPPERCASE_LETTER,
LOWERCASE_LETTER, TITLECASE_LETTER, MODIFIER_LETTER, OTHER_LETTER)
* it is a currency symbol (such as '$')
* it is a connecting punctuation character (such as '_')
* it is a digit
* it is a numeric letter (such as a Roman numeral character)
* it is a combining mark
* it is a non-spacing mark
* isIdentifierIgnorable returns true for the character
Parameters:
ch - the character to be tested.
Returns:
true if the character may be part of a Java identifier; false otherwise.
Since:
1.1
See Also:
isIdentifierIgnorable(char), isJavaIdentifierStart(char),
isLetterOrDigit(char), isUnicodeIdentifierPart(char)
[/quote]
The requirements above makes surrogates unsuitable for identifiers, simply
because surrogates have no suitable general category that matches the above
requirements:
* they are neither letters, currency symbols, and so on... because
surrogates have NO general category;
* the Character class just list them with a SURROGATE general category, see:
int Character.getType(Character ch);
* but it returns false for isDefined() as they don't have an entry in the
UCD or a value in a range defined in the UCD;
I doubt that this can be changed.
