You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tony Wu <wu...@gmail.com> on 2006/09/15 12:34:50 UTC
[classlib][luni]refactor some methods of j.l.Character
Hi all,
According the discussion on mailing list, I implement these new methods of
j.l.Character by delegating to ICU. But there were also some existing
methods with their own implementation and a couple of huge variables are
maintained for that.
Is it necessary to refactor these methods to delegate to ICU and remove
these huge String Objects?
--
Tony Wu
China Software Development Lab, IBM
Re: [classlib][luni]refactor some methods of j.l.Character
Posted by Tony Wu <wu...@gmail.com>.
On 9/16/06, Nathan Beyer <nb...@kc.rr.com> wrote:
>
> Can you give some specifics?
Yes, for example, many constants[1] are used to support these methods[2] .
Are you referring to the long string constants
> that are searched?
If delegate all these methods to ICU, all of the constantsinclude the long
string constants is no longer necessary.
Many of the current method need to be verified and uplifted to Unicode 4.1
> support, so modifying the implementations will be necessary in many cases.
Yes, I think so. I'll proceed to upgrade these method to Unicode 4.1compatible.
[1]
MIN_VALUE : char
MAX_VALUE : char
MIN_RADIX : int
MAX_RADIX : int
UNASSIGNED : byte
UPPERCASE_LETTER : byte
LOWERCASE_LETTER : byte
TITLECASE_LETTER : byte
MODIFIER_LETTER : byte
OTHER_LETTER : byte
NON_SPACING_MARK : byte
ENCLOSING_MARK : byte
COMBINING_SPACING_MARK : byte
DECIMAL_DIGIT_NUMBER : byte
LETTER_NUMBER : byte
OTHER_NUMBER : byte
SPACE_SEPARATOR : byte
LINE_SEPARATOR : byte
PARAGRAPH_SEPARATOR : byte
CONTROL : byte
FORMAT : byte
PRIVATE_USE : byte
SURROGATE : byte
DASH_PUNCTUATION : byte
START_PUNCTUATION : byte
END_PUNCTUATION : byte
CONNECTOR_PUNCTUATION : byte
OTHER_PUNCTUATION : byte
MATH_SYMBOL : byte
CURRENCY_SYMBOL : byte
MODIFIER_SYMBOL : byte
OTHER_SYMBOL : byte
INITIAL_QUOTE_PUNCTUATION : byte
FINAL_QUOTE_PUNCTUATION : byte
DIRECTIONALITY_UNDEFINED : byte
DIRECTIONALITY_LEFT_TO_RIGHT : byte
DIRECTIONALITY_RIGHT_TO_LEFT : byte
DIRECTIONALITY_RIGHT_TO_LEFT_ARABIC : byte
DIRECTIONALITY_EUROPEAN_NUMBER : byte
DIRECTIONALITY_EUROPEAN_NUMBER_SEPARATOR : byte
DIRECTIONALITY_EUROPEAN_NUMBER_TERMINATOR : byte
DIRECTIONALITY_ARABIC_NUMBER : byte
DIRECTIONALITY_COMMON_NUMBER_SEPARATOR : byte
DIRECTIONALITY_NONSPACING_MARK : byte
DIRECTIONALITY_BOUNDARY_NEUTRAL : byte
DIRECTIONALITY_PARAGRAPH_SEPARATOR : byte
DIRECTIONALITY_SEGMENT_SEPARATOR : byte
DIRECTIONALITY_WHITESPACE : byte
DIRECTIONALITY_OTHER_NEUTRALS : byte
DIRECTIONALITY_LEFT_TO_RIGHT_EMBEDDING : byte
DIRECTIONALITY_LEFT_TO_RIGHT_OVERRIDE : byte
DIRECTIONALITY_RIGHT_TO_LEFT_EMBEDDING : byte
DIRECTIONALITY_RIGHT_TO_LEFT_OVERRIDE : byte
DIRECTIONALITY_POP_DIRECTIONAL_FORMAT : byte
MIN_HIGH_SURROGATE : char
MAX_HIGH_SURROGATE : char
MIN_LOW_SURROGATE : char
MAX_LOW_SURROGATE : char
MIN_SURROGATE : char
MAX_SURROGATE : char
MIN_SUPPLEMENTARY_CODE_POINT : int
MIN_CODE_POINT : int
MAX_CODE_POINT : int
SIZE : int
bidiKeys : String
bidiValues : char[]
mirrored : char[]
typeKeys : String
typeValues : char[]
uppercaseKeys : String
uppercaseValues : char[]
lowercaseKeys : String
lowercaseValues : char[]
digitKeys : String
digitValues : char[]
typeTags : char[]
ISJAVASTART : int
ISJAVAPART : int
titlecaseKeys : String
titlecaseValues : char[]
numericKeys : String
numericValues : char[]
[2]
isHighSurrogate(char)
isLowSurrogate(char)
isSurrogatePair(char, char)
digit(char, int)
getNumericValue(char)
getType(char)
getDirectionality(char)
isMirrored(char)
isDefined(char)
isDigit(char)
isIdentifierIgnorable(char)
isISOControl(char)
isJavaIdentifierPart(char)
isJavaIdentifierStart(char)
isJavaLetter(char)
isJavaLetterOrDigit(char)
isLetter(char)
isLetterOrDigit(char)
isLowerCase(char)
isSpace(char)
isSpaceChar(char)
isTitleCase(char)
isUnicodeIdentifierPart(char)
isUnicodeIdentifierStart(char)
isUpperCase(char)
isWhitespace(char)
reverseBytes(char)
toLowerCase(char)
toTitleCase(char)
toUpperCase(char)
-Nathan
>
> > -----Original Message-----
> > From: Tony Wu [mailto:wuyuehao@gmail.com]
> > Sent: Friday, September 15, 2006 5:35 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: [classlib][luni]refactor some methods of j.l.Character
> >
> > Hi all,
> > According the discussion on mailing list, I implement these new methods
> of
> > j.l.Character by delegating to ICU. But there were also some existing
> > methods with their own implementation and a couple of huge variables are
> > maintained for that.
> > Is it necessary to refactor these methods to delegate to ICU and remove
> > these huge String Objects?
> >
> > --
> > Tony Wu
> > China Software Development Lab, IBM
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tony Wu
China Software Development Lab, IBM
RE: [classlib][luni]refactor some methods of j.l.Character
Posted by Nathan Beyer <nb...@kc.rr.com>.
Can you give some specifics? Are you referring to the long string constants
that are searched?
Many of the current method need to be verified and uplifted to Unicode 4.1
support, so modifying the implementations will be necessary in many cases.
-Nathan
> -----Original Message-----
> From: Tony Wu [mailto:wuyuehao@gmail.com]
> Sent: Friday, September 15, 2006 5:35 AM
> To: harmony-dev@incubator.apache.org
> Subject: [classlib][luni]refactor some methods of j.l.Character
>
> Hi all,
> According the discussion on mailing list, I implement these new methods of
> j.l.Character by delegating to ICU. But there were also some existing
> methods with their own implementation and a couple of huge variables are
> maintained for that.
> Is it necessary to refactor these methods to delegate to ICU and remove
> these huge String Objects?
>
> --
> Tony Wu
> China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org