You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Robert Muir (JIRA)" <ji...@apache.org> on 2010/09/14 22:12:47 UTC
[jira] Created: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
String.toLowerCase/toUpperCase incorrect for supplementary characters
---------------------------------------------------------------------
Key: HARMONY-6649
URL: https://issues.apache.org/jira/browse/HARMONY-6649
Project: Harmony
Issue Type: Bug
Components: Classlib
Affects Versions: 5.0M15
Reporter: Robert Muir
Simple testcase:
{code}
assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
{code}
Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [classlib] String.toLowerCase/toUpperCase incorrect for supplementary
characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 16/Sep/2010 16:04, Robert Muir wrote:
> On Thu, Sep 16, 2010 at 10:50 AM, Tim Ellison <t....@gmail.com> wrote:
>
>> The principle works ok. I attached a patch on HARMONY-6649 to show that
>> making a local toUpperCase() method for the charset names solves the
>> circularity problem in bootstrapping, and does the right thing
>> irrespective of locale.
>>
>> There are some compatibility issues though, since on the RI
>> String foo="foo";
>> foo.toLowerCase() == foo
>>
>> but it doesn't if we simply use ICU's toLowerCase method :-(
>>
>
> maybe we could ask ICU if they could fix this?
Yes, worth asking.
> i looked at their toLowerCase/toUpperCase methods and it wouldnt
> require too much hacking: their UCaseProps returns ~ch whenever ch
> 'folds to itself', so its easy to track if its 'unchanged' without
> doing a second pass/equals().
I'm deliberately not looking at the ICU impl, just so the work in
Harmony is all our own (avoid license confusion etc)
Since the uppercasing rules may depend upon context etc, I can only
imagine that we'll have to do the conversion via ICU then compare the
results to see if they are different. It will require a pass through
the char array again though.
public String toUpperCase(Locale locale) {
String result = UCharacter.toUpperCase(locale, this);
// Must return self if chars unchanged
if (count != result.count) {
return result;
}
for (int i = 0; i < count; i++) {
if (value[offset + i] != result.value[result.offset + i]) {
return result;
}
}
return this;
}
> they might be interested in improved compatibility also.
They may have compatibility issues the other way round, i.e. their users
expecting different objects back.
>> I also expect we need to fix String#equalsIgnoreCase() to do the right
>> thing...
>>
>
> yes, i noticed this too, we don't have to deal with Locale issues there, but
> we have to iterate codepoints / compare with Character.toLowerCase(int) and
> Character.toUpperCase(int)...
Ack
Regards,
Tim
Re: [classlib] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Robert Muir <rc...@gmail.com>.
On Thu, Sep 16, 2010 at 10:50 AM, Tim Ellison <t....@gmail.com> wrote:
>
> The principle works ok. I attached a patch on HARMONY-6649 to show that
> making a local toUpperCase() method for the charset names solves the
> circularity problem in bootstrapping, and does the right thing
> irrespective of locale.
>
> There are some compatibility issues though, since on the RI
> String foo="foo";
> foo.toLowerCase() == foo
>
> but it doesn't if we simply use ICU's toLowerCase method :-(
>
maybe we could ask ICU if they could fix this? i looked at their
toLowerCase/toUpperCase methods and it wouldnt require too much hacking:
their UCaseProps returns ~ch whenever ch 'folds to itself', so its easy to
track if its 'unchanged' without doing a second pass/equals().
they might be interested in improved compatibility also.
>
> I also expect we need to fix String#equalsIgnoreCase() to do the right
> thing...
>
>
yes, i noticed this too, we don't have to deal with Locale issues there, but
we have to iterate codepoints / compare with Character.toLowerCase(int) and
Character.toUpperCase(int)...
--
Robert Muir
rcmuir@gmail.com
Re: [classlib] String.toLowerCase/toUpperCase incorrect for supplementary
characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 16/Sep/2010 14:30, Robert Muir wrote:
> On Thu, Sep 16, 2010 at 9:26 AM, Tim Ellison <t....@gmail.com> wrote:
>
>> Yes, I agree (though I don't know what happens when it is uppercased
>> 'properly' in Turkish)
>>
>
> in this case it would be uppercased to US-ASCİİ (note the dotted i's)
>
>
>> Nah, the Charset name is obliged to be a strict subset of characters
>> [1], so I propose we just deal with the transform directly in
>> CharsetProviderImpl without asking Character.
>>
>> [1]
>>
>> http://download.oracle.com/javase/1.5.0/docs/api/java/nio/charset/Charset.html
>>
>>
> +1, seems like now i understand why this constraint exists!
The principle works ok. I attached a patch on HARMONY-6649 to show that
making a local toUpperCase() method for the charset names solves the
circularity problem in bootstrapping, and does the right thing
irrespective of locale.
There are some compatibility issues though, since on the RI
String foo="foo";
foo.toLowerCase() == foo
but it doesn't if we simply use ICU's toLowerCase method :-(
I also expect we need to fix String#equalsIgnoreCase() to do the right
thing...
Regards,
Tim
Re: [classlib] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Robert Muir <rc...@gmail.com>.
On Thu, Sep 16, 2010 at 9:26 AM, Tim Ellison <t....@gmail.com> wrote:
>
> Yes, I agree (though I don't know what happens when it is uppercased
> 'properly' in Turkish)
>
in this case it would be uppercased to US-ASCİİ (note the dotted i's)
>
> Nah, the Charset name is obliged to be a strict subset of characters
> [1], so I propose we just deal with the transform directly in
> CharsetProviderImpl without asking Character.
>
> [1]
>
> http://download.oracle.com/javase/1.5.0/docs/api/java/nio/charset/Charset.html
>
>
+1, seems like now i understand why this constraint exists!
--
Robert Muir
rcmuir@gmail.com
Re: [classlib] String.toLowerCase/toUpperCase incorrect for supplementary
characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 16/Sep/2010 14:16, Robert Muir wrote:
> On Thu, Sep 16, 2010 at 9:05 AM, Tim Ellison <t....@gmail.com> wrote:
>
>> On 16/Sep/2010 12:32, Robert Muir (JIRA) wrote:
>>> Does this mean harmony might need these methods for its own internal
>>> use before ICU is available?
>> Yes, String is used early in the bootstrapping, and having dependencies
>> on ICU functionality leads to an initialization circularity.
>>
>> i.e. if I simply implement String#toUpperCase(Locale) as
>> "return UCharacter.toUpperCase(locale, this)"
>> then we fail to boot with
>>
>> java.nio.charset.Charset (initialization failure)
>> at java/lang/String.defaultCharset (String.java:736)
>> at java/lang/String.<init> (String.java:232)
>> at org/apache/harmony/luni/util/Util.toString (Util.java:102)
>> at java/lang/System.getPropertyList (Native Method)
>> at java/lang/System.ensureProperties (System.java:546)
>> at java/lang/System.<clinit> (System.java:102)
>>
>> Likely because we use nio Charset in the String implementation, and that
>> in turn eventually calls String.toUppercase(), in CharsetProviderImpl
>> lines 113 and 145.
>
> Really I think this is a bug in CharsetProviderImpl.
> Because this calls toUpperCase with the default Locale, if i am on a Turkish
> computer, and i do Charset.forName("us-ascii"),
> its going to uppercase it turkish-style and it won't find the charset. but
> it will work fine most anywhere else.
Yes, I agree (though I don't know what happens when it is uppercased
'properly' in Turkish)
> I think this should be using Locale.ENGLISH here, as its a case-insensitive
> comparison, not intended for display.
>
> Or, optionally something closer to Unicode's 'simple case folding' could be
> available for situations like this, that simply iterates thru the string and
> does the Locale-insensitive Character.toLowerCase(i) on each character.
Nah, the Charset name is obliged to be a strict subset of characters
[1], so I propose we just deal with the transform directly in
CharsetProviderImpl without asking Character.
[1]
http://download.oracle.com/javase/1.5.0/docs/api/java/nio/charset/Charset.html
Regards,
Tim
Re: [classlib] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Robert Muir <rc...@gmail.com>.
On Thu, Sep 16, 2010 at 9:05 AM, Tim Ellison <t....@gmail.com> wrote:
> On 16/Sep/2010 12:32, Robert Muir (JIRA) wrote:
> > Does this mean harmony might need these methods for its own internal
> > use before ICU is available?
>
> Yes, String is used early in the bootstrapping, and having dependencies
> on ICU functionality leads to an initialization circularity.
>
> i.e. if I simply implement String#toUpperCase(Locale) as
> "return UCharacter.toUpperCase(locale, this)"
> then we fail to boot with
>
> java.nio.charset.Charset (initialization failure)
> at java/lang/String.defaultCharset (String.java:736)
> at java/lang/String.<init> (String.java:232)
> at org/apache/harmony/luni/util/Util.toString (Util.java:102)
> at java/lang/System.getPropertyList (Native Method)
> at java/lang/System.ensureProperties (System.java:546)
> at java/lang/System.<clinit> (System.java:102)
>
> Likely because we use nio Charset in the String implementation, and that
> in turn eventually calls String.toUppercase(), in CharsetProviderImpl
> lines 113 and 145.
>
>
Really I think this is a bug in CharsetProviderImpl.
Because this calls toUpperCase with the default Locale, if i am on a Turkish
computer, and i do Charset.forName("us-ascii"),
its going to uppercase it turkish-style and it won't find the charset. but
it will work fine most anywhere else.
I think this should be using Locale.ENGLISH here, as its a case-insensitive
comparison, not intended for display.
Or, optionally something closer to Unicode's 'simple case folding' could be
available for situations like this, that simply iterates thru the string and
does the Locale-insensitive Character.toLowerCase(i) on each character.
--
Robert Muir
rcmuir@gmail.com
[classlib] String.toLowerCase/toUpperCase incorrect for supplementary
characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 16/Sep/2010 12:32, Robert Muir (JIRA) wrote:
> Does this mean harmony might need these methods for its own internal
> use before ICU is available?
Yes, String is used early in the bootstrapping, and having dependencies
on ICU functionality leads to an initialization circularity.
i.e. if I simply implement String#toUpperCase(Locale) as
"return UCharacter.toUpperCase(locale, this)"
then we fail to boot with
java.nio.charset.Charset (initialization failure)
at java/lang/String.defaultCharset (String.java:736)
at java/lang/String.<init> (String.java:232)
at org/apache/harmony/luni/util/Util.toString (Util.java:102)
at java/lang/System.getPropertyList (Native Method)
at java/lang/System.ensureProperties (System.java:546)
at java/lang/System.<clinit> (System.java:102)
Likely because we use nio Charset in the String implementation, and that
in turn eventually calls String.toUppercase(), in CharsetProviderImpl
lines 113 and 145.
> When doing the toLowerCase(Locale)/toUpperCase(Locale), perhaps
> String.java could do:
>
> if (locale is not Turkish or Azeri or Lithuanian) while (ch < 0x7f) (
> just do optimized fast subtraction/addition ) ... // bail out
> completely and invoke 'UCharacter.xxx'
So I wrote a prototype version of this, that does the toUpperCase for
ascii (ch<128) in-lined (i.e. using simple math), then bailing out to
ICU for chars outside that range.
It seems to boot ok with that scheme, however, I'm running on a machine
with UK locale and running our code written in ascii text. I'll need to
think about whether the boot sequence could ever get to the point where
it needs to uppercase non-ascii.
It may be better to take out the calls of toUpperCase from nio Charset,
and have a local method to deal with those, since there are restrictions
on the strings that can be used to name charsets.
> this might be good for performance reasons?
Yes, though hopefully ICU also optimize the simple cases too.
> And harmony itself, if it uses this method at this point, is likely
> using Locale.ENGLISH or similar for consistent behavior (filenames,
> etc) ?
The locale is set up early, but ascii is ascii no matter the locale, so
uppercasing that simpler set should be fine.
> Sorry I'm not too familiar with the codebase so I'm not sure
> if it would work. But it might speed up 'typical' lowercasing in any
> case, and as far as worst-case 2x for the "special casing": i find
> the "special" casing is going to be slow anyway: e.g. the Greek sigma
> example needs to calculate word boundaries!
>
> the Turkish/Azeri case is trickier than the existing code, I think it
> should use UCharacter.XXX too. The reason is it has to be able to
> handle the case from SpecialCasing where the 'dotted I' is written in
> decomposed form (e.g. I + COMBINING DOT ABOVE)
Yep, I'm happy to let ICU handle these interesting cases.
Regards,
Tim
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910101#action_12910101 ]
Robert Muir commented on HARMONY-6649:
--------------------------------------
Does this mean harmony might need these methods for its own internal use before ICU is available?
When doing the toLowerCase(Locale)/toUpperCase(Locale), perhaps String.java could do:
if (locale is not Turkish or Azeri or Lithuanian)
while (ch < 0x7f)
( just do optimized fast subtraction/addition )
...
// bail out completely and invoke 'UCharacter.xxx'
this might be good for performance reasons? And harmony itself, if it uses this method at this point, is likely using Locale.ENGLISH or similar for consistent behavior (filenames, etc) ? Sorry I'm not too familiar with the codebase so I'm not sure if it would work. But it might speed up 'typical' lowercasing in any case, and as far as worst-case 2x for the "special casing": i find the "special" casing is going to be slow anyway: e.g. the Greek sigma example needs to calculate word boundaries!
the Turkish/Azeri case is trickier than the existing code, I think it should use UCharacter.XXX too.
The reason is it has to be able to handle the case from SpecialCasing where the 'dotted I' is written in decomposed form (e.g. I + COMBINING DOT ABOVE)
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910538#action_12910538 ]
Hudson commented on HARMONY-6649:
---------------------------------
Integrated in Harmony-select-1.5-head-linux-x86_64 #110 (See [https://hudson.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/110/])
Apply fix for HARMONY-6649 (String.toLowerCase/toUpperCase incorrect for supplementary characters)
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Attachments: harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison resolved HARMONY-6649.
----------------------------------
Resolution: Fixed
Patch to String was re-applied at repo revision r1000700 (after file permission changes).
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_filepermission.patch, HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910548#action_12910548 ]
Hudson commented on HARMONY-6649:
---------------------------------
Integrated in Harmony-1.5-head-linux-x86_64 #949 (See [https://hudson.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/949/])
Apply fix for HARMONY-6649 (String.toLowerCase/toUpperCase incorrect for supplementary characters)
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Attachments: harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914171#action_12914171 ]
Hudson commented on HARMONY-6649:
---------------------------------
Integrated in Harmony-select-1.5-head-linux-x86_64 #119 (See [https://hudson.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/119/])
Backing out changes for HARMONY-6649 (String.toLowerCase/toUpperCase incorrect for supplementary characters)
to get the build working again.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_filepermission.patch, HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914156#action_12914156 ]
Hudson commented on HARMONY-6649:
---------------------------------
Integrated in Harmony-1.5-head-linux-x86_64 #964 (See [https://hudson.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/964/])
Backing out changes for HARMONY-6649 (String.toLowerCase/toUpperCase incorrect for supplementary characters)
to get the build working again.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_filepermission.patch, HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison updated HARMONY-6649:
---------------------------------
Attachment: harmony6649.patch
Attaching file harmony6649.patch which is a *prototype* of the changes required for discussion.
It needs more more work because on the RI
String foo = "foo";
foo.toLowerCase() == foo
but it doesn't on this prototype, courtesy of ICU...
Also needs work on equalsIgnoreCase I expect.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Attachments: harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909744#action_12909744 ]
Robert Muir commented on HARMONY-6649:
--------------------------------------
I started looking at this to try to produce a patch, but I found more problems.
For example, this Locale-sensitive lowerCase does not appear to handle greek final sigma correctly, or various other things
from SpecialCasing (http://www.unicode.org/Public/4.0-Update/SpecialCasing-4.0.0.txt)
To implement the casing algorithms here from Unicode ch3.13 is quite complex, is it possible
for String.toLowerCase(Locale)/toUpperCase(Locale) to somehow use the ICU static methods in UCharacter?
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison resolved HARMONY-6649.
----------------------------------
Fix Version/s: 5.0M15
Resolution: Fixed
I applied you regression test in LUNI module at repo revision r999591.
Please verify by closing this issue that it was applied as you expected. Let's open a new issue for the equalsIgnoreCase.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison reassigned HARMONY-6649:
------------------------------------
Assignee: Tim Ellison
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910086#action_12910086 ]
Tim Ellison commented on HARMONY-6649:
--------------------------------------
... though if it is used as part of the bootstrapping of the class libraries there may need to be some way to do toUpperCase until we are ready to load ICU.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914342#action_12914342 ]
Hudson commented on HARMONY-6649:
---------------------------------
Integrated in Harmony-1.5-head-linux-x86_64 #966 (See [https://hudson.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/966/])
Re-apply fix for HARMONY-6649 (String.toLowerCase/toUpperCase incorrect for supplementary characters)
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_filepermission.patch, HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914334#action_12914334 ]
Hudson commented on HARMONY-6649:
---------------------------------
Integrated in Harmony-select-1.5-head-linux-x86_64 #120 (See [https://hudson.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/120/])
Re-apply fix for HARMONY-6649 (String.toLowerCase/toUpperCase incorrect for supplementary characters)
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_filepermission.patch, HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Sep 24, 2010 at 1:13 AM, Robert Muir <rc...@gmail.com> wrote:
>
> but case-sensitive filenames (such as windows) don't use locale-dependent
> comparisons?
> they implement locale-independent case-folding. for example if i have a
> file "σ.txt", I cannot create "ς.txt". (I just tried)
> Both of these files are already in lowercase.
>
> The interesting question is: how does hashCode() relate? Because a hashcode
> based upon String.toLowerCase(Locale.ENGLISH) would return different
> hashcodes for these two filenames, but with UCharacter.foldCase(), it would
> be the same.
>
i did more tests here against windows, and looking at the api link you
provided:
http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
<http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29>windows
appears to implement something closer to 'simple case folding':
http://icu-project.org/apiref/icu4j/com/ibm/icu/lang/UCharacter.html#foldCase(int,
boolean), not the 'full case folding'. For example I can create "ss.txt" and
"ß.txt"
windows also doesn't lowercase any supplementary characters.
In other words, its case comparison acts exactly like
String.equalsIgnoreCase(). So, for File.hashCode(), a hashcode computed with
Character.toLowerCase(Character.toUpperCase(char)) would be completely
consistent with its case sensitivity.
--
Robert Muir
rcmuir@gmail.com
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by sebb <se...@gmail.com>.
On 24 September 2010 07:31, Robert Muir <rc...@gmail.com> wrote:
> On Fri, Sep 24, 2010 at 2:27 AM, Tim Ellison <t....@gmail.com> wrote:
>
>>
>> No, I don't think it is a problem. I was reviewing the invokers of
>> toLowerCase() and was confused by the wording in the spec. I'm happy
>> that we should simply lowercase it in a locale independent way, and
>> don't need to do a "windows equals" implementation.
>>
>
> Ok, but sure seems like a bug to me.
>
> File f1 = new File("σ.txt");
> File f2 = new File("ς.txt");
> System.out.println(f1.hashCode());
> System.out.println(f2.hashCode());
> System.out.println(f1.equals(f2));
>
> 889962580
> 890776533
> true
Here are my results for the equivalent code (easier to compile, as no
need to specify encoding):
File f1 = new File("\u03c3.txt");
File f2 = new File("\u03c2.txt");
I also added:
System.out.println(f2.getCanonicalPath().equals(f1.getCanonicalPath()));
Windows XP: Java 1.5.0 & Java 1.6.0
889962580
890776533
true
true|false - if the file exists before comparing canonicalPaths, then
true, else false.
Minotaur: Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
889962580
890776533
false
true - does not depend on whether the file exists
Note the change in equals. However, createFile() does not create a
different file.
ISTM that the Windows code should not generate different canonical
paths depending on the contents of the directory.
Not sure about the Un*x code - it seems odd to have equal canonical
paths, but different Files
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Sep 24, 2010 at 2:27 AM, Tim Ellison <t....@gmail.com> wrote:
>
> No, I don't think it is a problem. I was reviewing the invokers of
> toLowerCase() and was confused by the wording in the spec. I'm happy
> that we should simply lowercase it in a locale independent way, and
> don't need to do a "windows equals" implementation.
>
Ok, but sure seems like a bug to me.
File f1 = new File("σ.txt");
File f2 = new File("ς.txt");
System.out.println(f1.hashCode());
System.out.println(f2.hashCode());
System.out.println(f1.equals(f2));
889962580
890776533
true
--
Robert Muir
rcmuir@gmail.com
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 24/Sep/2010 08:17, Deven You wrote:
> I have saw the error before, and I have some investigation of it. I think
> the root cause is the commit change the class load order. Before this
> commit, Locale class will be loaded before ULocale class And after this
> commit, ULocale is loaded before Locale.
>
> The direct cause is CharsetProviderImpl no longer use String.toUpperCase,
> instead it uses its own toUpperCase. And String.toUpperCase calls
> String.toUpperCase(Locale), this ensure Locale class will be loaded before
> ULocale. However CharsetProviderImpl own toUpperCase uses no Locale, so it
> causes Locale class loaded after ULocale.
>
> To solve this problem, a work around could simply be below:
> 1.Add a Locale static field in String:
> private static Locale defaulLocale = new Locale.getDefaultLocale();
> ...
> 2. Change the String.toUpperCase() from calling
> toUpperCase(Locale.getDefaultLocale()) to toUpperCase(defaultLocale)
>
> above change could solve the NullPointerException mentioned by Mohan, but I
> am not sure if it is a good design.
No, because it would give the wrong answer when the
Locale#setDefault(Locale) is used later.
Regards,
Tim
> Caused by: java.lang.NullPointerException
> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> at java.util.Locale.<init>(Locale.java:228)
> at java.util.Locale.<init>(Locale.java:201)
> at java.util.Locale.<clinit>(Locale.java:51)
> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>
>
>
>
>
> 2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
>
>> On loading junit.jar[2] i get initialization exception[3]. This
>> exception disappears if i revert the patch committed for
>> (HARMONY-6649) toUpper/toLowerCase.
>>
>> Make sure your junit.jar contains the signature files[1]. (use the
>> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
>> commit, I am not able to load the jar file if it's manifest contains
>> any signature related files. Any thought on this?
>>
>>
>> [1] jar -tvf junit.jar
>> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
>> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
>> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
>> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
>> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
>> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
>> ............
>>
>> [2] run command : java -cp junit.jar junit.textui.TestRunner
>>
>> [3] Exception:
>> Uncaught exception in main:
>> java.lang.ExceptionInInitializerError
>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>> at
>> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
>> e.java:810)
>> at
>> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
>> e.java:801)
>> at
>> com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
>> )
>> at
>> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
>> va:536)
>> at
>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>> va:144)
>> at
>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>> va:124)
>> at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
>> at
>> java.security.AccessController.doPrivilegedImpl(AccessController.java
>> :171)
>> at
>> java.security.AccessController.doPrivileged(AccessController.java:53)
>>
>> at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
>> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
>> at java.util.TimeZone.<clinit>(TimeZone.java:91)
>> at
>> org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
>> ava:51)
>> at
>> org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
>> 96)
>> at
>> org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
>> 0)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
>> (BerInputStream.java:755)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
>> eam.java:733)
>> at
>> org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
>> eam.java:138)
>> at
>> org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
>> at
>> org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
>> a:140)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at
>> org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
>> at
>> org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
>> entInfo.java:153)
>> at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:53)
>> at
>> org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
>> ava:73)
>> at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
>> at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
>> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
>> at
>> java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
>> :402)
>> at
>> java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
>> 71)
>> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
>> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
>> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
>> at
>> java.security.AccessController.doPrivilegedImpl(AccessController.java
>> :171)
>> at
>> java.security.AccessController.doPrivileged(AccessController.java:64)
>>
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
>> at
>> java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
>> 0)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
>> Caused by: java.lang.NullPointerException
>> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
>> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
>> at java.util.Locale.<init>(Locale.java:228)
>> at java.util.Locale.<init>(Locale.java:201)
>> at java.util.Locale.<clinit>(Locale.java:51)
>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>> ... 54 more
>> FAILED to invoke JVM.
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com>
>> wrote:
>>> On 24/Sep/2010 06:58, Robert Muir wrote:
>>>> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com>
>> wrote:
>>>>> System.out.println(new File("σ.txt").hashCode());
>>>>> System.out.println(new File("ς.txt").hashCode());
>>>>>
>>>>> prints out
>>>>>
>>>>> 889962580
>>>>> 890776533
>>>>>
>>>>> on both Harmony and the RI.
>>>>>
>>>>>
>>>> but perhaps this is just a bug in the RI?
>>>> according to the link:
>>>>
>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>>>> <
>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>>> Because
>>>> equality of abstract pathnames is inherently system-dependent, so is the
>>>> computation of their hash codes.
>>>>
>>>> Is it a problem that "windows equals" is inconsistent with hashCode
>> here? I
>>>> admit these are corner cases.
>>> No, I don't think it is a problem. I was reviewing the invokers of
>>> toLowerCase() and was confused by the wording in the spec. I'm happy
>>> that we should simply lowercase it in a locale independent way, and
>>> don't need to do a "windows equals" implementation.
>>>
>>> Regards,
>>> Tim
>>>
>>
>>
>> --
>> Mohan
>>
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 24/Sep/2010 17:08, Deven You wrote:
> It is a bit complex. First of all, I meet this problem because when I run
> specjbb benchmark, at the during of vm startup, it returned just the same
> error mentioned by Mohan.
>
> Then I used java -verbose to show the boot classes load order, compared to
> harmony build between before this commit and after this commit and saw:
> before this commit, Locale is first loaded, and then ULocale loaded
> after this commit, ULocale is first loaded, and then Locale is loaded. this
> build will return the above NPE error.
>
> Then I went on to check why with this commit, Locale won't be loaded before
> ULocale, I found before this commit,at the vm start up, CharsetProviderImpl
> will be invoked, it will invoke String.toUpperCase() which in turn invoke
> String.toUpperCase(Locale.getDefault()), at this point, Locale class will be
> loaded, and also at this point, there is no class used ULoclae yet, so
> ULocale is not loadede yet. And again at this point, Locale class will
> invoke ULocale class, so sequentially ULocale will be used thus loaded
> during Locale class init.
>
> After with this commit, now CharsetPorviderImple will invoke its own
> toUpperCase() method which dose not depend on Locale class any longer, so at
> the point CharsetProviderImple is invoked, it dose not need Locale, so
> Locale class won't be loaded at this point.
The bit I was wondering about is this...
> Later for some reason, maybe other class need ULoclae, so ULocale is
> loaded.
We don't expose ULocale though our APIs, so it must be our own usage
that is causing this load. I was wondering if you had found that first
reference, which would help us figure out the load sequence.
Regards,
Tim
> Again at that point, Locale
> class is still not loaded. With this condition, ULocale will invoke Locale
> methods, so Locale class will be loaded during ULocale class init. This
> cause Locale class is loaded after ULocale class.
>
> Unfortunately, Current ULocale class will meet NPE exception with above
> situation: Locale class is loaded after ULocale class. The root cause is
> that:
> ULocale class init will initialize below static field:
> public static final ULocale ENGLISH = new ULocale("en", Locale.ENGLISH);
> This cause Locale will be loaded, during Locale class init, below static
> field will be initialized:
> public static final Locale CANADA = new Locale("en", "CA");
> new Locale("en", "CA"); will finally calls new ULocale(language, country,
> variant) and which will invoke getName(String localeID) and which will
> execute:
> String name = nameCache.get(localeID), here, nameCache is a static
> field of ULocale, from above call sequence, we can see the ULocale class
> just execute to initialize new ULocale("en", Locale.ENGLISH). It have no
> chance to initialze nameCache yet, so at this point, the java will throw NPE
> exception.
>
> If Locale is loaded before ULocale, from Locale initialization process, the
> code logic and interaction mechanism between Locale and ULocale just by
> chance can avoid such situation and execute successfully.
>
> I am not sure this is enough for you. Any unclear things please point out to
> me. Thanks a lot!
>
>
>
>
>
> From current Local and ULocale code logic. Locale class initialization
> process will call ULocale, it cause ULocal class init.
>
> 2010/9/24 Tim Ellison <t....@gmail.com>
>
>> On 24/Sep/2010 08:17, Deven You wrote:
>>> I have saw the error before, and I have some investigation of it. I think
>>> the root cause is the commit change the class load order. Before this
>>> commit, Locale class will be loaded before ULocale class And after this
>>> commit, ULocale is loaded before Locale.
>> I'm not near the code right now so can you explain this to me please?
>> IIRC the Locale and ULocale are mutually dependent so will be loaded
>> together anyway. There is an 'early' initialization in Locale to set up
>> the US-en values for booting.
>>
>> So my question is where is the reference to ULocale being made earlier
>> now? and how did this change the behavior as it existed before.
>>
>> Regards,
>> Tim
>>
>>> The direct cause is CharsetProviderImpl no longer use String.toUpperCase,
>>> instead it uses its own toUpperCase. And String.toUpperCase calls
>>> String.toUpperCase(Locale), this ensure Locale class will be loaded
>> before
>>> ULocale. However CharsetProviderImpl own toUpperCase uses no Locale, so
>> it
>>> causes Locale class loaded after ULocale.
>>>
>>> To solve this problem, a work around could simply be below:
>>> 1.Add a Locale static field in String:
>>> private static Locale defaulLocale = new Locale.getDefaultLocale();
>>> ...
>>> 2. Change the String.toUpperCase() from calling
>>> toUpperCase(Locale.getDefaultLocale()) to toUpperCase(defaultLocale)
>>>
>>> above change could solve the NullPointerException mentioned by Mohan, but
>> I
>>> am not sure if it is a good design.
>>>
>>> Caused by: java.lang.NullPointerException
>>> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
>>> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
>>> at java.util.Locale.<init>(Locale.java:228)
>>> at java.util.Locale.<init>(Locale.java:201)
>>> at java.util.Locale.<clinit>(Locale.java:51)
>>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>>>
>>>
>>>
>>>
>>>
>>> 2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
>>>
>>>> On loading junit.jar[2] i get initialization exception[3]. This
>>>> exception disappears if i revert the patch committed for
>>>> (HARMONY-6649) toUpper/toLowerCase.
>>>>
>>>> Make sure your junit.jar contains the signature files[1]. (use the
>>>> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
>>>> commit, I am not able to load the jar file if it's manifest contains
>>>> any signature related files. Any thought on this?
>>>>
>>>>
>>>> [1] jar -tvf junit.jar
>>>> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
>>>> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
>>>> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
>>>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
>>>> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
>>>> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
>>>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
>>>> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
>>>> ............
>>>>
>>>> [2] run command : java -cp junit.jar junit.textui.TestRunner
>>>>
>>>> [3] Exception:
>>>> Uncaught exception in main:
>>>> java.lang.ExceptionInInitializerError
>>>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>>>> at
>>>> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
>>>> e.java:810)
>>>> at
>>>> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
>>>> e.java:801)
>>>> at
>>>> com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
>>>> )
>>>> at
>>>> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
>>>> va:536)
>>>> at
>>>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>>>> va:144)
>>>> at
>>>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>>>> va:124)
>>>> at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
>>>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
>>>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
>>>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
>>>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
>>>> at
>>>> java.security.AccessController.doPrivilegedImpl(AccessController.java
>>>> :171)
>>>> at
>>>> java.security.AccessController.doPrivileged(AccessController.java:53)
>>>>
>>>> at
>> java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
>>>> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
>>>> at java.util.TimeZone.<clinit>(TimeZone.java:91)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
>>>> ava:51)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
>>>> 96)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
>>>> 0)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>>>> Stream.java:665)
>>>> at
>>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>>>> Stream.java:125)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>>>> a:48)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>>>> Stream.java:665)
>>>> at
>>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>>>> Stream.java:125)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>>>> a:48)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>>>> Stream.java:665)
>>>> at
>>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>>>> Stream.java:125)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>>>> a:48)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
>>>> (BerInputStream.java:755)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
>>>> eam.java:733)
>>>> at
>>>> org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
>>>> eam.java:138)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
>>>> a:140)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>>>> Stream.java:665)
>>>> at
>>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>>>> Stream.java:125)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>>>> a:48)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
>>>> at
>>>> org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
>>>> entInfo.java:153)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>>>> a:53)
>>>> at
>>>> org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
>>>> ava:73)
>>>> at
>> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
>>>> at
>> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
>>>> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
>>>> at
>>>> java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
>>>> :402)
>>>> at
>>>> java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
>>>> 71)
>>>> at
>> java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
>>>> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
>>>> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
>>>> at
>>>> java.security.AccessController.doPrivilegedImpl(AccessController.java
>>>> :171)
>>>> at
>>>> java.security.AccessController.doPrivileged(AccessController.java:64)
>>>>
>>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
>>>> at
>>>> java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
>>>> 0)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
>>>> Caused by: java.lang.NullPointerException
>>>> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
>>>> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
>>>> at java.util.Locale.<init>(Locale.java:228)
>>>> at java.util.Locale.<init>(Locale.java:201)
>>>> at java.util.Locale.<clinit>(Locale.java:51)
>>>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>>>> ... 54 more
>>>> FAILED to invoke JVM.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com>
>>>> wrote:
>>>>> On 24/Sep/2010 06:58, Robert Muir wrote:
>>>>>> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com>
>>>> wrote:
>>>>>>> System.out.println(new File("σ.txt").hashCode());
>>>>>>> System.out.println(new File("ς.txt").hashCode());
>>>>>>>
>>>>>>> prints out
>>>>>>>
>>>>>>> 889962580
>>>>>>> 890776533
>>>>>>>
>>>>>>> on both Harmony and the RI.
>>>>>>>
>>>>>>>
>>>>>> but perhaps this is just a bug in the RI?
>>>>>> according to the link:
>>>>>>
>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>>>>>> <
>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>>>>> Because
>>>>>> equality of abstract pathnames is inherently system-dependent, so is
>> the
>>>>>> computation of their hash codes.
>>>>>>
>>>>>> Is it a problem that "windows equals" is inconsistent with hashCode
>>>> here? I
>>>>>> admit these are corner cases.
>>>>> No, I don't think it is a problem. I was reviewing the invokers of
>>>>> toLowerCase() and was confused by the wording in the spec. I'm happy
>>>>> that we should simply lowercase it in a locale independent way, and
>>>>> don't need to do a "windows equals" implementation.
>>>>>
>>>>> Regards,
>>>>> Tim
>>>>>
>>>>
>>>> --
>>>> Mohan
>>>>
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Regis <xu...@gmail.com>.
On 2010-09-30 13:44, Regis wrote:
> On 2010-09-27 10:26, Deven You wrote:
>> I have tested this patch on my local machine, Ubuntu10.04 x86. It works
>> well.
>>
>> 2010/9/27 Tim Ellison<t....@gmail.com>
>>
>>> On 24/Sep/2010 17:51, Deven You wrote:
>>>> Here is the result of Specjbb
>>>
>>> I don't have a copy of Specjbb to try, so sorry it broke that. I think
>>> I can set up a harmony unit test to emulate the problem here once we
>>> have an acceptable solution.
>>>
>>> Snipped stack trace follows...
>>>> java.util.Locale (initialization failure)
>>>> Caused by: java.lang.NullPointerException
>>>> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
>>>> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
>>>> at java.util.Locale.<init>(Locale.java:234)
>>>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>>>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
>>>> at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
>>>> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
>>>> at java.util.TimeZone.<clinit>(TimeZone.java:91)
>>>
>
> The problem is not completely resolved, could happen in another loading
> path (may be even more):
>
> run
>
> Collator.getAvailableLocales();
>
> got
>
> java.lang.ExceptionInInitializerError
> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> at
> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundle.java:810)
>
> at
> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundle.java:801)
>
> at com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489)
> at
> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.java:536)
>
> at
> com.ibm.icu.impl.ICUResourceBundle.createULocaleList(ICUResourceBundle.java:509)
>
> at com.ibm.icu.impl.ICUResourceBundle.access$100(ICUResourceBundle.java:38)
> at
> com.ibm.icu.impl.ICUResourceBundle$AvailEntry.getULocaleList(ICUResourceBundle.java:691)
>
> at
> com.ibm.icu.impl.ICUResourceBundle.createLocaleList(ICUResourceBundle.java:530)
>
> at com.ibm.icu.impl.ICUResourceBundle.access$200(ICUResourceBundle.java:38)
> at
> com.ibm.icu.impl.ICUResourceBundle$AvailEntry.getLocaleList(ICUResourceBundle.java:697)
>
> at
> com.ibm.icu.impl.ICUResourceBundle.getAvailableLocales(ICUResourceBundle.java:449)
>
> at com.ibm.icu.text.Collator.getAvailableLocales(Collator.java:566)
> at java.text.Collator.getAvailableLocales(Collator.java:277)
> at TestMain.main(TestMain.java:57)
> Caused by: java.lang.NullPointerException
> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> at java.util.Locale.<init>(Locale.java:228)
> at java.util.Locale.<init>(Locale.java:201)
> at java.util.Locale.<clinit>(Locale.java:51)
> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> ... 14 more
>
> and seems Deven's patch works here, but will see another exception may
> be caused by new version icu4j 4.4.1.1
>
> java.lang.NullPointerException
> at
> com.ibm.icu.impl.ICUResourceBundle.createBundle(ICUResourceBundle.java:1008)
>
> at
> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundle.java:833)
>
> at
> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundle.java:801)
>
> at com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489)
> at
> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.java:536)
>
> at
> com.ibm.icu.impl.ICUResourceBundle.createULocaleList(ICUResourceBundle.java:509)
>
> at com.ibm.icu.impl.ICUResourceBundle.access$100(ICUResourceBundle.java:38)
> at
> com.ibm.icu.impl.ICUResourceBundle$AvailEntry.getULocaleList(ICUResourceBundle.java:691)
>
> at
> com.ibm.icu.impl.ICUResourceBundle.createLocaleList(ICUResourceBundle.java:530)
>
> at com.ibm.icu.impl.ICUResourceBundle.access$200(ICUResourceBundle.java:38)
> at
> com.ibm.icu.impl.ICUResourceBundle$AvailEntry.getLocaleList(ICUResourceBundle.java:697)
>
> at
> com.ibm.icu.impl.ICUResourceBundle.getAvailableLocales(ICUResourceBundle.java:449)
>
> at com.ibm.icu.text.Collator.getAvailableLocales(Collator.java:566)
> at java.text.Collator.getAvailableLocales(Collator.java:277)
> at TestMain.main(TestMain.java:57)
>
This NPE is because icu4j need a classloader to create ResourceBundle, it get
classloader like this:
ClassLoader cl = Collator.class.getClassLoader();
In Harmony, Collator is bootstrap classloader, so cl is null, but icu4j doesn't
check 'null' here. I can't find any way to workaround it in Harmony's code.
--
Best Regards,
Regis.
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Regis <xu...@gmail.com>.
On 2010-09-27 10:26, Deven You wrote:
> I have tested this patch on my local machine, Ubuntu10.04 x86. It works
> well.
>
> 2010/9/27 Tim Ellison<t....@gmail.com>
>
>> On 24/Sep/2010 17:51, Deven You wrote:
>>> Here is the result of Specjbb
>>
>> I don't have a copy of Specjbb to try, so sorry it broke that. I think
>> I can set up a harmony unit test to emulate the problem here once we
>> have an acceptable solution.
>>
>> Snipped stack trace follows...
>>> java.util.Locale (initialization failure)
>>> Caused by: java.lang.NullPointerException
>>> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
>>> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
>>> at java.util.Locale.<init>(Locale.java:234)
>>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
>>> at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
>>> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
>>> at java.util.TimeZone.<clinit>(TimeZone.java:91)
>>
The problem is not completely resolved, could happen in another loading path
(may be even more):
run
Collator.getAvailableLocales();
got
java.lang.ExceptionInInitializerError
at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
at com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundle.java:810)
at com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundle.java:801)
at com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489)
at com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.java:536)
at com.ibm.icu.impl.ICUResourceBundle.createULocaleList(ICUResourceBundle.java:509)
at com.ibm.icu.impl.ICUResourceBundle.access$100(ICUResourceBundle.java:38)
at
com.ibm.icu.impl.ICUResourceBundle$AvailEntry.getULocaleList(ICUResourceBundle.java:691)
at com.ibm.icu.impl.ICUResourceBundle.createLocaleList(ICUResourceBundle.java:530)
at com.ibm.icu.impl.ICUResourceBundle.access$200(ICUResourceBundle.java:38)
at
com.ibm.icu.impl.ICUResourceBundle$AvailEntry.getLocaleList(ICUResourceBundle.java:697)
at
com.ibm.icu.impl.ICUResourceBundle.getAvailableLocales(ICUResourceBundle.java:449)
at com.ibm.icu.text.Collator.getAvailableLocales(Collator.java:566)
at java.text.Collator.getAvailableLocales(Collator.java:277)
at TestMain.main(TestMain.java:57)
Caused by: java.lang.NullPointerException
at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
at java.util.Locale.<init>(Locale.java:228)
at java.util.Locale.<init>(Locale.java:201)
at java.util.Locale.<clinit>(Locale.java:51)
at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
... 14 more
and seems Deven's patch works here, but will see another exception may be caused
by new version icu4j 4.4.1.1
java.lang.NullPointerException
at com.ibm.icu.impl.ICUResourceBundle.createBundle(ICUResourceBundle.java:1008)
at com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundle.java:833)
at com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundle.java:801)
at com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489)
at com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.java:536)
at com.ibm.icu.impl.ICUResourceBundle.createULocaleList(ICUResourceBundle.java:509)
at com.ibm.icu.impl.ICUResourceBundle.access$100(ICUResourceBundle.java:38)
at
com.ibm.icu.impl.ICUResourceBundle$AvailEntry.getULocaleList(ICUResourceBundle.java:691)
at com.ibm.icu.impl.ICUResourceBundle.createLocaleList(ICUResourceBundle.java:530)
at com.ibm.icu.impl.ICUResourceBundle.access$200(ICUResourceBundle.java:38)
at
com.ibm.icu.impl.ICUResourceBundle$AvailEntry.getLocaleList(ICUResourceBundle.java:697)
at
com.ibm.icu.impl.ICUResourceBundle.getAvailableLocales(ICUResourceBundle.java:449)
at com.ibm.icu.text.Collator.getAvailableLocales(Collator.java:566)
at java.text.Collator.getAvailableLocales(Collator.java:277)
at TestMain.main(TestMain.java:57)
--
Best Regards,
Regis.
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Deven You <de...@gmail.com>.
I have tested this patch on my local machine, Ubuntu10.04 x86. It works
well.
2010/9/27 Tim Ellison <t....@gmail.com>
> On 24/Sep/2010 17:51, Deven You wrote:
> > Here is the result of Specjbb
>
> I don't have a copy of Specjbb to try, so sorry it broke that. I think
> I can set up a harmony unit test to emulate the problem here once we
> have an acceptable solution.
>
> Snipped stack trace follows...
> > java.util.Locale (initialization failure)
> > Caused by: java.lang.NullPointerException
> > at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> > at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> > at java.util.Locale.<init>(Locale.java:234)
> > at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> > at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
> > at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
> > at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
> > at java.util.TimeZone.<clinit>(TimeZone.java:91)
>
> > I have marked several important stack invocations as red and bold.
>
> Sorry, the red and bold were lost for me, however, I've gone through and
> trimmed down the stack aggressively to show the key parts.
>
> > From above stack trace, Class load process will invoke security
> > methods which will use TimeZone and TimeZone will finally depend on
> > ULocale.
> >
> > I think if our harmony apis need Locale TimeZone info, it always depends
> on
> > icu's ULocale, TimeZone and etc. It can not be avoided during Java
> startup.
>
> Well in this case, yes we do need a TimeZone as part of the certificate
> decoding, but in general we might not need Locale info, so I'm reluctant
> to force a j.u.Locale load too early e.g. by a reference from String.
>
> The 'correct' fix is to change the ICU code to load Locale earlier, I
> guess they don't expect to be early on the boot sequence. Given we
> can't/don't want to modify ICU for our needs here, I've added (r1001490)
> a reference to Locale during the TimeZone definition to force the load.
> Please can you check that fixes the problem you see on Specjbb?
>
> There may be other cases that need us to initialize ICU, and I'll look
> for them. If you have any better ideas of how to get the ordering right
> please say.
>
> Regards,
> Tim
>
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 24/Sep/2010 17:51, Deven You wrote:
> Here is the result of Specjbb
I don't have a copy of Specjbb to try, so sorry it broke that. I think
I can set up a harmony unit test to emulate the problem here once we
have an acceptable solution.
Snipped stack trace follows...
> java.util.Locale (initialization failure)
> Caused by: java.lang.NullPointerException
> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> at java.util.Locale.<init>(Locale.java:234)
> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
> at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
> at java.util.TimeZone.<clinit>(TimeZone.java:91)
> I have marked several important stack invocations as red and bold.
Sorry, the red and bold were lost for me, however, I've gone through and
trimmed down the stack aggressively to show the key parts.
> From above stack trace, Class load process will invoke security
> methods which will use TimeZone and TimeZone will finally depend on
> ULocale.
>
> I think if our harmony apis need Locale TimeZone info, it always depends on
> icu's ULocale, TimeZone and etc. It can not be avoided during Java startup.
Well in this case, yes we do need a TimeZone as part of the certificate
decoding, but in general we might not need Locale info, so I'm reluctant
to force a j.u.Locale load too early e.g. by a reference from String.
The 'correct' fix is to change the ICU code to load Locale earlier, I
guess they don't expect to be early on the boot sequence. Given we
can't/don't want to modify ICU for our needs here, I've added (r1001490)
a reference to Locale during the TimeZone definition to force the load.
Please can you check that fixes the problem you see on Specjbb?
There may be other cases that need us to initialize ICU, and I'll look
for them. If you have any better ideas of how to get the ordering right
please say.
Regards,
Tim
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Deven You <de...@gmail.com>.
Here is the result of Specjbb
deven@deven:~/temp/SPECjbb2005$ ~/see-git/target/hdk/jdk/jre/bin/java -cp
check.jar:jbb.jar:PTA.jar spec.jbb.JBBmain -propfile SPECjbb.props 2>&1
java.lang.NoClassDefFoundError: java.util.Locale (initialization failure)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:145)
at org.apache.harmony.luni.util.Msg.<clinit>(Unknown Source)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:205)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:783)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:777)
at java.lang.Thread.uncaughtException(Thread.java:1320)
Caused by: java.lang.NullPointerException
at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
at java.util.Locale.<init>(Locale.java:234)
at java.util.Locale.<init>(Locale.java:207)
at java.util.Locale.<clinit>(Locale.java:51)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:205)
* **at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)*
* **at java.lang.J9VMInternals.initializeImpl(Native Method)*
* **at java.lang.J9VMInternals.initialize(J9VMInternals.java:205)*
at
com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundle.java:810)
at
com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundle.java:801)
at com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489)
at
com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.java:536)
at
com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.java:144)
at
com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.java:124)
at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
at java.security.AccessController.doPrivileged(AccessController.java:186)
at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
* **at java.util.TimeZone.<clinit>(TimeZone.java:91)*
* **at java.lang.J9VMInternals.initializeImpl(Native Method)*
* **at java.lang.J9VMInternals.initialize(J9VMInternals.java:205)*
at
org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.java:51)
at org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:96)
at org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:320)
at
org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInputStream.java:665)
at
org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInputStream.java:125)
at
org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.java:48)
at
org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInputStream.java:665)
at
org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInputStream.java:125)
at
org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.java:48)
at
org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInputStream.java:665)
at
org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInputStream.java:125)
at
org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.java:48)
at
org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection(BerInputStream.java:756)
at
org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStream.java:733)
at
org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStream.java:138)
at org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
at
org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.java:140)
at
org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInputStream.java:665)
at
org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInputStream.java:125)
at
org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.java:48)
at org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
at
org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(ContentInfo.java:153)
at
org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.java:53)
* **at
org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.java:73)
*
at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
at java.util.jar.JarFile.getInputStream(JarFile.java:392)
at
java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java:402)
at java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:371)
at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1220)
at java.net.URLClassLoader$4.run(URLClassLoader.java:908)
at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
at java.security.AccessController.doPrivileged(AccessController.java:209)
at java.net.URLClassLoader.findClass(URLClassLoader.java:905)
at
com.ibm.oti.vm.URLSystemClassLoader.findClass(URLSystemClassLoader.java:26)
at java.lang.ClassLoader.loadClass(ClassLoader.java:665)
at com.ibm.oti.vm.URLAppClassLoader.loadClass(URLAppClassLoader.java:115)
* **at java.lang.ClassLoader.loadClass(ClassLoader.java:631)*
*...*
*
*
I have marked several important stack invocations as red and bold. From
above stack trace, Class load process will invoke security methods which
will use TimeZone and TimeZone will finally depend on ULocale.
I think if our harmony apis need Locale TimeZone info, it always depends on
icu's ULocale, TimeZone and etc. It can not be avoided during Java startup.
2010/9/25 Tim Ellison <t....@gmail.com>
> On 24/Sep/2010 17:08, Deven You wrote:
> > It is a bit complex. First of all, I meet this problem because when I run
> > specjbb benchmark, at the during of vm startup, it returned just the same
> > error mentioned by Mohan.
> >
> > Then I used java -verbose to show the boot classes load order, compared
> to
> > harmony build between before this commit and after this commit and saw:
> > before this commit, Locale is first loaded, and then ULocale loaded
> > after this commit, ULocale is first loaded, and then Locale is loaded.
> this
> > build will return the above NPE error.
> >
> > Then I went on to check why with this commit, Locale won't be loaded
> before
> > ULocale, I found before this commit,at the vm start up,
> CharsetProviderImpl
> > will be invoked, it will invoke String.toUpperCase() which in turn invoke
> > String.toUpperCase(Locale.getDefault()), at this point, Locale class will
> be
> > loaded, and also at this point, there is no class used ULoclae yet, so
> > ULocale is not loadede yet. And again at this point, Locale class will
> > invoke ULocale class, so sequentially ULocale will be used thus loaded
> > during Locale class init.
> >
> > After with this commit, now CharsetPorviderImple will invoke its own
> > toUpperCase() method which dose not depend on Locale class any longer, so
> at
> > the point CharsetProviderImple is invoked, it dose not need Locale, so
> > Locale class won't be loaded at this point.
>
> The bit I was wondering about is this...
>
> > Later for some reason, maybe other class need ULoclae, so ULocale is
> > loaded.
>
> We don't expose ULocale though our APIs, so it must be our own usage
> that is causing this load. I was wondering if you had found that first
> reference, which would help us figure out the load sequence.
>
> Regards,
> Tim
>
> > Again at that point, Locale
> > class is still not loaded. With this condition, ULocale will invoke
> Locale
> > methods, so Locale class will be loaded during ULocale class init. This
> > cause Locale class is loaded after ULocale class.
> >
> > Unfortunately, Current ULocale class will meet NPE exception with above
> > situation: Locale class is loaded after ULocale class. The root cause is
> > that:
> > ULocale class init will initialize below static field:
> > public static final ULocale ENGLISH = new ULocale("en", Locale.ENGLISH);
> > This cause Locale will be loaded, during Locale class init, below static
> > field will be initialized:
> > public static final Locale CANADA = new Locale("en", "CA");
> > new Locale("en", "CA"); will finally calls new ULocale(language, country,
> > variant) and which will invoke getName(String localeID) and which will
> > execute:
> > String name = nameCache.get(localeID), here, nameCache is a static
> > field of ULocale, from above call sequence, we can see the ULocale class
> > just execute to initialize new ULocale("en", Locale.ENGLISH). It have no
> > chance to initialze nameCache yet, so at this point, the java will throw
> NPE
> > exception.
> >
> > If Locale is loaded before ULocale, from Locale initialization process,
> the
> > code logic and interaction mechanism between Locale and ULocale just by
> > chance can avoid such situation and execute successfully.
> >
> > I am not sure this is enough for you. Any unclear things please point out
> to
> > me. Thanks a lot!
> >
> >
> >
> >
> >
> > From current Local and ULocale code logic. Locale class initialization
> > process will call ULocale, it cause ULocal class init.
> >
> > 2010/9/24 Tim Ellison <t....@gmail.com>
> >
> >> On 24/Sep/2010 08:17, Deven You wrote:
> >>> I have saw the error before, and I have some investigation of it. I
> think
> >>> the root cause is the commit change the class load order. Before this
> >>> commit, Locale class will be loaded before ULocale class And after this
> >>> commit, ULocale is loaded before Locale.
> >> I'm not near the code right now so can you explain this to me please?
> >> IIRC the Locale and ULocale are mutually dependent so will be loaded
> >> together anyway. There is an 'early' initialization in Locale to set up
> >> the US-en values for booting.
> >>
> >> So my question is where is the reference to ULocale being made earlier
> >> now? and how did this change the behavior as it existed before.
> >>
> >> Regards,
> >> Tim
> >>
> >>> The direct cause is CharsetProviderImpl no longer use
> String.toUpperCase,
> >>> instead it uses its own toUpperCase. And String.toUpperCase calls
> >>> String.toUpperCase(Locale), this ensure Locale class will be loaded
> >> before
> >>> ULocale. However CharsetProviderImpl own toUpperCase uses no Locale, so
> >> it
> >>> causes Locale class loaded after ULocale.
> >>>
> >>> To solve this problem, a work around could simply be below:
> >>> 1.Add a Locale static field in String:
> >>> private static Locale defaulLocale = new Locale.getDefaultLocale();
> >>> ...
> >>> 2. Change the String.toUpperCase() from calling
> >>> toUpperCase(Locale.getDefaultLocale()) to toUpperCase(defaultLocale)
> >>>
> >>> above change could solve the NullPointerException mentioned by Mohan,
> but
> >> I
> >>> am not sure if it is a good design.
> >>>
> >>> Caused by: java.lang.NullPointerException
> >>> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> >>> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> >>> at java.util.Locale.<init>(Locale.java:228)
> >>> at java.util.Locale.<init>(Locale.java:201)
> >>> at java.util.Locale.<clinit>(Locale.java:51)
> >>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
> >>>
> >>>> On loading junit.jar[2] i get initialization exception[3]. This
> >>>> exception disappears if i revert the patch committed for
> >>>> (HARMONY-6649) toUpper/toLowerCase.
> >>>>
> >>>> Make sure your junit.jar contains the signature files[1]. (use the
> >>>> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
> >>>> commit, I am not able to load the jar file if it's manifest contains
> >>>> any signature related files. Any thought on this?
> >>>>
> >>>>
> >>>> [1] jar -tvf junit.jar
> >>>> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
> >>>> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
> >>>> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
> >>>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
> >>>> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
> >>>> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
> >>>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
> >>>> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
> >>>> ............
> >>>>
> >>>> [2] run command : java -cp junit.jar junit.textui.TestRunner
> >>>>
> >>>> [3] Exception:
> >>>> Uncaught exception in main:
> >>>> java.lang.ExceptionInInitializerError
> >>>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >>>> at
> >>>> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
> >>>> e.java:810)
> >>>> at
> >>>> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
> >>>> e.java:801)
> >>>> at
> >>>> com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
> >>>> )
> >>>> at
> >>>> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
> >>>> va:536)
> >>>> at
> >>>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> >>>> va:144)
> >>>> at
> >>>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> >>>> va:124)
> >>>> at
> com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
> >>>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
> >>>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
> >>>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
> >>>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
> >>>> at
> >>>> java.security.AccessController.doPrivilegedImpl(AccessController.java
> >>>> :171)
> >>>> at
> >>>> java.security.AccessController.doPrivileged(AccessController.java:53)
> >>>>
> >>>> at
> >> java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
> >>>> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
> >>>> at java.util.TimeZone.<clinit>(TimeZone.java:91)
> >>>> at
> >>>> org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
> >>>> ava:51)
> >>>> at
> >>>> org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
> >>>> 96)
> >>>> at
> >>>> org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
> >>>> 0)
> >>>> at
> >>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >>>> Stream.java:665)
> >>>> at
> >>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >>>> Stream.java:125)
> >>>> at
> >>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >>>> a:48)
> >>>> at
> >>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >>>> Stream.java:665)
> >>>> at
> >>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >>>> Stream.java:125)
> >>>> at
> >>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >>>> a:48)
> >>>> at
> >>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >>>> Stream.java:665)
> >>>> at
> >>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >>>> Stream.java:125)
> >>>> at
> >>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >>>> a:48)
> >>>> at
> >>>> org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
> >>>> (BerInputStream.java:755)
> >>>> at
> >>>> org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
> >>>> eam.java:733)
> >>>> at
> >>>> org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
> >>>> eam.java:138)
> >>>> at
> >>>> org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
> >>>> at
> >>>> org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
> >>>> a:140)
> >>>> at
> >>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >>>> Stream.java:665)
> >>>> at
> >>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >>>> Stream.java:125)
> >>>> at
> >>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >>>> a:48)
> >>>> at
> >>>> org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
> >>>> at
> >>>> org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
> >>>> entInfo.java:153)
> >>>> at
> >>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >>>> a:53)
> >>>> at
> >>>> org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
> >>>> ava:73)
> >>>> at
> >> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
> >>>> at
> >> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
> >>>> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
> >>>> at
> >>>> java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
> >>>> :402)
> >>>> at
> >>>> java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
> >>>> 71)
> >>>> at
> >> java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
> >>>> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
> >>>> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
> >>>> at
> >>>> java.security.AccessController.doPrivilegedImpl(AccessController.java
> >>>> :171)
> >>>> at
> >>>> java.security.AccessController.doPrivileged(AccessController.java:64)
> >>>>
> >>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
> >>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
> >>>> at
> >>>> java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
> >>>> 0)
> >>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
> >>>> Caused by: java.lang.NullPointerException
> >>>> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> >>>> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> >>>> at java.util.Locale.<init>(Locale.java:228)
> >>>> at java.util.Locale.<init>(Locale.java:201)
> >>>> at java.util.Locale.<clinit>(Locale.java:51)
> >>>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >>>> ... 54 more
> >>>> FAILED to invoke JVM.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com>
> >>>> wrote:
> >>>>> On 24/Sep/2010 06:58, Robert Muir wrote:
> >>>>>> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t.p.ellison@gmail.com
> >
> >>>> wrote:
> >>>>>>> System.out.println(new File("σ.txt").hashCode());
> >>>>>>> System.out.println(new File("ς.txt").hashCode());
> >>>>>>>
> >>>>>>> prints out
> >>>>>>>
> >>>>>>> 889962580
> >>>>>>> 890776533
> >>>>>>>
> >>>>>>> on both Harmony and the RI.
> >>>>>>>
> >>>>>>>
> >>>>>> but perhaps this is just a bug in the RI?
> >>>>>> according to the link:
> >>>>>>
> >>
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >>>>>> <
> >>
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >>>>> Because
> >>>>>> equality of abstract pathnames is inherently system-dependent, so is
> >> the
> >>>>>> computation of their hash codes.
> >>>>>>
> >>>>>> Is it a problem that "windows equals" is inconsistent with hashCode
> >>>> here? I
> >>>>>> admit these are corner cases.
> >>>>> No, I don't think it is a problem. I was reviewing the invokers of
> >>>>> toLowerCase() and was confused by the wording in the spec. I'm happy
> >>>>> that we should simply lowercase it in a locale independent way, and
> >>>>> don't need to do a "windows equals" implementation.
> >>>>>
> >>>>> Regards,
> >>>>> Tim
> >>>>>
> >>>>
> >>>> --
> >>>> Mohan
> >>>>
> >
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 24/Sep/2010 17:08, Deven You wrote:
> It is a bit complex. First of all, I meet this problem because when I run
> specjbb benchmark, at the during of vm startup, it returned just the same
> error mentioned by Mohan.
>
> Then I used java -verbose to show the boot classes load order, compared to
> harmony build between before this commit and after this commit and saw:
> before this commit, Locale is first loaded, and then ULocale loaded
> after this commit, ULocale is first loaded, and then Locale is loaded. this
> build will return the above NPE error.
>
> Then I went on to check why with this commit, Locale won't be loaded before
> ULocale, I found before this commit,at the vm start up, CharsetProviderImpl
> will be invoked, it will invoke String.toUpperCase() which in turn invoke
> String.toUpperCase(Locale.getDefault()), at this point, Locale class will be
> loaded, and also at this point, there is no class used ULoclae yet, so
> ULocale is not loadede yet. And again at this point, Locale class will
> invoke ULocale class, so sequentially ULocale will be used thus loaded
> during Locale class init.
>
> After with this commit, now CharsetPorviderImple will invoke its own
> toUpperCase() method which dose not depend on Locale class any longer, so at
> the point CharsetProviderImple is invoked, it dose not need Locale, so
> Locale class won't be loaded at this point.
The bit I was wondering about is this...
> Later for some reason, maybe other class need ULoclae, so ULocale is
> loaded.
We don't expose ULocale though our APIs, so it must be our own usage
that is causing this load. I was wondering if you had found that first
reference, which would help us figure out the load sequence.
Regards,
Tim
> Again at that point, Locale
> class is still not loaded. With this condition, ULocale will invoke Locale
> methods, so Locale class will be loaded during ULocale class init. This
> cause Locale class is loaded after ULocale class.
>
> Unfortunately, Current ULocale class will meet NPE exception with above
> situation: Locale class is loaded after ULocale class. The root cause is
> that:
> ULocale class init will initialize below static field:
> public static final ULocale ENGLISH = new ULocale("en", Locale.ENGLISH);
> This cause Locale will be loaded, during Locale class init, below static
> field will be initialized:
> public static final Locale CANADA = new Locale("en", "CA");
> new Locale("en", "CA"); will finally calls new ULocale(language, country,
> variant) and which will invoke getName(String localeID) and which will
> execute:
> String name = nameCache.get(localeID), here, nameCache is a static
> field of ULocale, from above call sequence, we can see the ULocale class
> just execute to initialize new ULocale("en", Locale.ENGLISH). It have no
> chance to initialze nameCache yet, so at this point, the java will throw NPE
> exception.
>
> If Locale is loaded before ULocale, from Locale initialization process, the
> code logic and interaction mechanism between Locale and ULocale just by
> chance can avoid such situation and execute successfully.
>
> I am not sure this is enough for you. Any unclear things please point out to
> me. Thanks a lot!
>
>
>
>
>
> From current Local and ULocale code logic. Locale class initialization
> process will call ULocale, it cause ULocal class init.
>
> 2010/9/24 Tim Ellison <t....@gmail.com>
>
>> On 24/Sep/2010 08:17, Deven You wrote:
>>> I have saw the error before, and I have some investigation of it. I think
>>> the root cause is the commit change the class load order. Before this
>>> commit, Locale class will be loaded before ULocale class And after this
>>> commit, ULocale is loaded before Locale.
>> I'm not near the code right now so can you explain this to me please?
>> IIRC the Locale and ULocale are mutually dependent so will be loaded
>> together anyway. There is an 'early' initialization in Locale to set up
>> the US-en values for booting.
>>
>> So my question is where is the reference to ULocale being made earlier
>> now? and how did this change the behavior as it existed before.
>>
>> Regards,
>> Tim
>>
>>> The direct cause is CharsetProviderImpl no longer use String.toUpperCase,
>>> instead it uses its own toUpperCase. And String.toUpperCase calls
>>> String.toUpperCase(Locale), this ensure Locale class will be loaded
>> before
>>> ULocale. However CharsetProviderImpl own toUpperCase uses no Locale, so
>> it
>>> causes Locale class loaded after ULocale.
>>>
>>> To solve this problem, a work around could simply be below:
>>> 1.Add a Locale static field in String:
>>> private static Locale defaulLocale = new Locale.getDefaultLocale();
>>> ...
>>> 2. Change the String.toUpperCase() from calling
>>> toUpperCase(Locale.getDefaultLocale()) to toUpperCase(defaultLocale)
>>>
>>> above change could solve the NullPointerException mentioned by Mohan, but
>> I
>>> am not sure if it is a good design.
>>>
>>> Caused by: java.lang.NullPointerException
>>> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
>>> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
>>> at java.util.Locale.<init>(Locale.java:228)
>>> at java.util.Locale.<init>(Locale.java:201)
>>> at java.util.Locale.<clinit>(Locale.java:51)
>>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>>>
>>>
>>>
>>>
>>>
>>> 2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
>>>
>>>> On loading junit.jar[2] i get initialization exception[3]. This
>>>> exception disappears if i revert the patch committed for
>>>> (HARMONY-6649) toUpper/toLowerCase.
>>>>
>>>> Make sure your junit.jar contains the signature files[1]. (use the
>>>> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
>>>> commit, I am not able to load the jar file if it's manifest contains
>>>> any signature related files. Any thought on this?
>>>>
>>>>
>>>> [1] jar -tvf junit.jar
>>>> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
>>>> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
>>>> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
>>>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
>>>> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
>>>> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
>>>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
>>>> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
>>>> ............
>>>>
>>>> [2] run command : java -cp junit.jar junit.textui.TestRunner
>>>>
>>>> [3] Exception:
>>>> Uncaught exception in main:
>>>> java.lang.ExceptionInInitializerError
>>>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>>>> at
>>>> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
>>>> e.java:810)
>>>> at
>>>> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
>>>> e.java:801)
>>>> at
>>>> com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
>>>> )
>>>> at
>>>> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
>>>> va:536)
>>>> at
>>>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>>>> va:144)
>>>> at
>>>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>>>> va:124)
>>>> at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
>>>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
>>>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
>>>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
>>>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
>>>> at
>>>> java.security.AccessController.doPrivilegedImpl(AccessController.java
>>>> :171)
>>>> at
>>>> java.security.AccessController.doPrivileged(AccessController.java:53)
>>>>
>>>> at
>> java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
>>>> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
>>>> at java.util.TimeZone.<clinit>(TimeZone.java:91)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
>>>> ava:51)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
>>>> 96)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
>>>> 0)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>>>> Stream.java:665)
>>>> at
>>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>>>> Stream.java:125)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>>>> a:48)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>>>> Stream.java:665)
>>>> at
>>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>>>> Stream.java:125)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>>>> a:48)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>>>> Stream.java:665)
>>>> at
>>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>>>> Stream.java:125)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>>>> a:48)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
>>>> (BerInputStream.java:755)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
>>>> eam.java:733)
>>>> at
>>>> org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
>>>> eam.java:138)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
>>>> a:140)
>>>> at
>>>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>>>> Stream.java:665)
>>>> at
>>>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>>>> Stream.java:125)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>>>> a:48)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
>>>> at
>>>> org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
>>>> entInfo.java:153)
>>>> at
>>>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>>>> a:53)
>>>> at
>>>> org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
>>>> ava:73)
>>>> at
>> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
>>>> at
>> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
>>>> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
>>>> at
>>>> java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
>>>> :402)
>>>> at
>>>> java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
>>>> 71)
>>>> at
>> java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
>>>> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
>>>> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
>>>> at
>>>> java.security.AccessController.doPrivilegedImpl(AccessController.java
>>>> :171)
>>>> at
>>>> java.security.AccessController.doPrivileged(AccessController.java:64)
>>>>
>>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
>>>> at
>>>> java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
>>>> 0)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
>>>> Caused by: java.lang.NullPointerException
>>>> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
>>>> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
>>>> at java.util.Locale.<init>(Locale.java:228)
>>>> at java.util.Locale.<init>(Locale.java:201)
>>>> at java.util.Locale.<clinit>(Locale.java:51)
>>>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>>>> ... 54 more
>>>> FAILED to invoke JVM.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com>
>>>> wrote:
>>>>> On 24/Sep/2010 06:58, Robert Muir wrote:
>>>>>> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com>
>>>> wrote:
>>>>>>> System.out.println(new File("σ.txt").hashCode());
>>>>>>> System.out.println(new File("ς.txt").hashCode());
>>>>>>>
>>>>>>> prints out
>>>>>>>
>>>>>>> 889962580
>>>>>>> 890776533
>>>>>>>
>>>>>>> on both Harmony and the RI.
>>>>>>>
>>>>>>>
>>>>>> but perhaps this is just a bug in the RI?
>>>>>> according to the link:
>>>>>>
>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>>>>>> <
>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>>>>> Because
>>>>>> equality of abstract pathnames is inherently system-dependent, so is
>> the
>>>>>> computation of their hash codes.
>>>>>>
>>>>>> Is it a problem that "windows equals" is inconsistent with hashCode
>>>> here? I
>>>>>> admit these are corner cases.
>>>>> No, I don't think it is a problem. I was reviewing the invokers of
>>>>> toLowerCase() and was confused by the wording in the spec. I'm happy
>>>>> that we should simply lowercase it in a locale independent way, and
>>>>> don't need to do a "windows equals" implementation.
>>>>>
>>>>> Regards,
>>>>> Tim
>>>>>
>>>>
>>>> --
>>>> Mohan
>>>>
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Deven You <de...@gmail.com>.
It is a bit complex. First of all, I meet this problem because when I run
specjbb benchmark, at the during of vm startup, it returned just the same
error mentioned by Mohan.
Then I used java -verbose to show the boot classes load order, compared to
harmony build between before this commit and after this commit and saw:
before this commit, Locale is first loaded, and then ULocale loaded
after this commit, ULocale is first loaded, and then Locale is loaded. this
build will return the above NPE error.
Then I went on to check why with this commit, Locale won't be loaded before
ULocale, I found before this commit,at the vm start up, CharsetProviderImpl
will be invoked, it will invoke String.toUpperCase() which in turn invoke
String.toUpperCase(Locale.getDefault()), at this point, Locale class will be
loaded, and also at this point, there is no class used ULoclae yet, so
ULocale is not loadede yet. And again at this point, Locale class will
invoke ULocale class, so sequentially ULocale will be used thus loaded
during Locale class init.
After with this commit, now CharsetPorviderImple will invoke its own
toUpperCase() method which dose not depend on Locale class any longer, so at
the point CharsetProviderImple is invoked, it dose not need Locale, so
Locale class won't be loaded at this point. Later for some reason, maybe
other class need ULoclae, so ULocale is loaded. Again at that point, Locale
class is still not loaded. With this condition, ULocale will invoke Locale
methods, so Locale class will be loaded during ULocale class init. This
cause Locale class is loaded after ULocale class.
Unfortunately, Current ULocale class will meet NPE exception with above
situation: Locale class is loaded after ULocale class. The root cause is
that:
ULocale class init will initialize below static field:
public static final ULocale ENGLISH = new ULocale("en", Locale.ENGLISH);
This cause Locale will be loaded, during Locale class init, below static
field will be initialized:
public static final Locale CANADA = new Locale("en", "CA");
new Locale("en", "CA"); will finally calls new ULocale(language, country,
variant) and which will invoke getName(String localeID) and which will
execute:
String name = nameCache.get(localeID), here, nameCache is a static
field of ULocale, from above call sequence, we can see the ULocale class
just execute to initialize new ULocale("en", Locale.ENGLISH). It have no
chance to initialze nameCache yet, so at this point, the java will throw NPE
exception.
If Locale is loaded before ULocale, from Locale initialization process, the
code logic and interaction mechanism between Locale and ULocale just by
chance can avoid such situation and execute successfully.
I am not sure this is enough for you. Any unclear things please point out to
me. Thanks a lot!
From current Local and ULocale code logic. Locale class initialization
process will call ULocale, it cause ULocal class init.
2010/9/24 Tim Ellison <t....@gmail.com>
> On 24/Sep/2010 08:17, Deven You wrote:
> > I have saw the error before, and I have some investigation of it. I think
> > the root cause is the commit change the class load order. Before this
> > commit, Locale class will be loaded before ULocale class And after this
> > commit, ULocale is loaded before Locale.
>
> I'm not near the code right now so can you explain this to me please?
> IIRC the Locale and ULocale are mutually dependent so will be loaded
> together anyway. There is an 'early' initialization in Locale to set up
> the US-en values for booting.
>
> So my question is where is the reference to ULocale being made earlier
> now? and how did this change the behavior as it existed before.
>
> Regards,
> Tim
>
> > The direct cause is CharsetProviderImpl no longer use String.toUpperCase,
> > instead it uses its own toUpperCase. And String.toUpperCase calls
> > String.toUpperCase(Locale), this ensure Locale class will be loaded
> before
> > ULocale. However CharsetProviderImpl own toUpperCase uses no Locale, so
> it
> > causes Locale class loaded after ULocale.
> >
> > To solve this problem, a work around could simply be below:
> > 1.Add a Locale static field in String:
> > private static Locale defaulLocale = new Locale.getDefaultLocale();
> > ...
> > 2. Change the String.toUpperCase() from calling
> > toUpperCase(Locale.getDefaultLocale()) to toUpperCase(defaultLocale)
> >
> > above change could solve the NullPointerException mentioned by Mohan, but
> I
> > am not sure if it is a good design.
> >
> > Caused by: java.lang.NullPointerException
> > at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> > at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> > at java.util.Locale.<init>(Locale.java:228)
> > at java.util.Locale.<init>(Locale.java:201)
> > at java.util.Locale.<clinit>(Locale.java:51)
> > at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >
> >
> >
> >
> >
> > 2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
> >
> >> On loading junit.jar[2] i get initialization exception[3]. This
> >> exception disappears if i revert the patch committed for
> >> (HARMONY-6649) toUpper/toLowerCase.
> >>
> >> Make sure your junit.jar contains the signature files[1]. (use the
> >> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
> >> commit, I am not able to load the jar file if it's manifest contains
> >> any signature related files. Any thought on this?
> >>
> >>
> >> [1] jar -tvf junit.jar
> >> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
> >> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
> >> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
> >> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
> >> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
> >> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
> >> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
> >> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
> >> ............
> >>
> >> [2] run command : java -cp junit.jar junit.textui.TestRunner
> >>
> >> [3] Exception:
> >> Uncaught exception in main:
> >> java.lang.ExceptionInInitializerError
> >> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >> at
> >> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
> >> e.java:810)
> >> at
> >> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
> >> e.java:801)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
> >> )
> >> at
> >> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
> >> va:536)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> >> va:144)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> >> va:124)
> >> at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
> >> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
> >> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
> >> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
> >> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
> >> at
> >> java.security.AccessController.doPrivilegedImpl(AccessController.java
> >> :171)
> >> at
> >> java.security.AccessController.doPrivileged(AccessController.java:53)
> >>
> >> at
> java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
> >> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
> >> at java.util.TimeZone.<clinit>(TimeZone.java:91)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
> >> ava:51)
> >> at
> >> org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
> >> 96)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
> >> 0)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
> >> (BerInputStream.java:755)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
> >> eam.java:733)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
> >> eam.java:138)
> >> at
> >> org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
> >> a:140)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
> >> at
> >> org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
> >> entInfo.java:153)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:53)
> >> at
> >> org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
> >> ava:73)
> >> at
> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
> >> at
> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
> >> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
> >> at
> >> java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
> >> :402)
> >> at
> >> java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
> >> 71)
> >> at
> java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
> >> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
> >> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
> >> at
> >> java.security.AccessController.doPrivilegedImpl(AccessController.java
> >> :171)
> >> at
> >> java.security.AccessController.doPrivileged(AccessController.java:64)
> >>
> >> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
> >> at
> >> java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
> >> 0)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
> >> Caused by: java.lang.NullPointerException
> >> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> >> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> >> at java.util.Locale.<init>(Locale.java:228)
> >> at java.util.Locale.<init>(Locale.java:201)
> >> at java.util.Locale.<clinit>(Locale.java:51)
> >> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >> ... 54 more
> >> FAILED to invoke JVM.
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com>
> >> wrote:
> >>> On 24/Sep/2010 06:58, Robert Muir wrote:
> >>>> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com>
> >> wrote:
> >>>>> System.out.println(new File("σ.txt").hashCode());
> >>>>> System.out.println(new File("ς.txt").hashCode());
> >>>>>
> >>>>> prints out
> >>>>>
> >>>>> 889962580
> >>>>> 890776533
> >>>>>
> >>>>> on both Harmony and the RI.
> >>>>>
> >>>>>
> >>>> but perhaps this is just a bug in the RI?
> >>>> according to the link:
> >>>>
> >>
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >>>> <
> >>
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >>> Because
> >>>> equality of abstract pathnames is inherently system-dependent, so is
> the
> >>>> computation of their hash codes.
> >>>>
> >>>> Is it a problem that "windows equals" is inconsistent with hashCode
> >> here? I
> >>>> admit these are corner cases.
> >>> No, I don't think it is a problem. I was reviewing the invokers of
> >>> toLowerCase() and was confused by the wording in the spec. I'm happy
> >>> that we should simply lowercase it in a locale independent way, and
> >>> don't need to do a "windows equals" implementation.
> >>>
> >>> Regards,
> >>> Tim
> >>>
> >>
> >>
> >> --
> >> Mohan
> >>
> >
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 24/Sep/2010 08:17, Deven You wrote:
> I have saw the error before, and I have some investigation of it. I think
> the root cause is the commit change the class load order. Before this
> commit, Locale class will be loaded before ULocale class And after this
> commit, ULocale is loaded before Locale.
I'm not near the code right now so can you explain this to me please?
IIRC the Locale and ULocale are mutually dependent so will be loaded
together anyway. There is an 'early' initialization in Locale to set up
the US-en values for booting.
So my question is where is the reference to ULocale being made earlier
now? and how did this change the behavior as it existed before.
Regards,
Tim
> The direct cause is CharsetProviderImpl no longer use String.toUpperCase,
> instead it uses its own toUpperCase. And String.toUpperCase calls
> String.toUpperCase(Locale), this ensure Locale class will be loaded before
> ULocale. However CharsetProviderImpl own toUpperCase uses no Locale, so it
> causes Locale class loaded after ULocale.
>
> To solve this problem, a work around could simply be below:
> 1.Add a Locale static field in String:
> private static Locale defaulLocale = new Locale.getDefaultLocale();
> ...
> 2. Change the String.toUpperCase() from calling
> toUpperCase(Locale.getDefaultLocale()) to toUpperCase(defaultLocale)
>
> above change could solve the NullPointerException mentioned by Mohan, but I
> am not sure if it is a good design.
>
> Caused by: java.lang.NullPointerException
> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> at java.util.Locale.<init>(Locale.java:228)
> at java.util.Locale.<init>(Locale.java:201)
> at java.util.Locale.<clinit>(Locale.java:51)
> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>
>
>
>
>
> 2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
>
>> On loading junit.jar[2] i get initialization exception[3]. This
>> exception disappears if i revert the patch committed for
>> (HARMONY-6649) toUpper/toLowerCase.
>>
>> Make sure your junit.jar contains the signature files[1]. (use the
>> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
>> commit, I am not able to load the jar file if it's manifest contains
>> any signature related files. Any thought on this?
>>
>>
>> [1] jar -tvf junit.jar
>> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
>> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
>> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
>> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
>> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
>> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
>> ............
>>
>> [2] run command : java -cp junit.jar junit.textui.TestRunner
>>
>> [3] Exception:
>> Uncaught exception in main:
>> java.lang.ExceptionInInitializerError
>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>> at
>> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
>> e.java:810)
>> at
>> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
>> e.java:801)
>> at
>> com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
>> )
>> at
>> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
>> va:536)
>> at
>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>> va:144)
>> at
>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>> va:124)
>> at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
>> at
>> java.security.AccessController.doPrivilegedImpl(AccessController.java
>> :171)
>> at
>> java.security.AccessController.doPrivileged(AccessController.java:53)
>>
>> at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
>> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
>> at java.util.TimeZone.<clinit>(TimeZone.java:91)
>> at
>> org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
>> ava:51)
>> at
>> org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
>> 96)
>> at
>> org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
>> 0)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
>> (BerInputStream.java:755)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
>> eam.java:733)
>> at
>> org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
>> eam.java:138)
>> at
>> org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
>> at
>> org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
>> a:140)
>> at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at
>> org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
>> at
>> org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
>> entInfo.java:153)
>> at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:53)
>> at
>> org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
>> ava:73)
>> at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
>> at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
>> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
>> at
>> java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
>> :402)
>> at
>> java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
>> 71)
>> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
>> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
>> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
>> at
>> java.security.AccessController.doPrivilegedImpl(AccessController.java
>> :171)
>> at
>> java.security.AccessController.doPrivileged(AccessController.java:64)
>>
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
>> at
>> java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
>> 0)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
>> Caused by: java.lang.NullPointerException
>> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
>> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
>> at java.util.Locale.<init>(Locale.java:228)
>> at java.util.Locale.<init>(Locale.java:201)
>> at java.util.Locale.<clinit>(Locale.java:51)
>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>> ... 54 more
>> FAILED to invoke JVM.
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com>
>> wrote:
>>> On 24/Sep/2010 06:58, Robert Muir wrote:
>>>> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com>
>> wrote:
>>>>> System.out.println(new File("σ.txt").hashCode());
>>>>> System.out.println(new File("ς.txt").hashCode());
>>>>>
>>>>> prints out
>>>>>
>>>>> 889962580
>>>>> 890776533
>>>>>
>>>>> on both Harmony and the RI.
>>>>>
>>>>>
>>>> but perhaps this is just a bug in the RI?
>>>> according to the link:
>>>>
>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>>>> <
>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>>> Because
>>>> equality of abstract pathnames is inherently system-dependent, so is the
>>>> computation of their hash codes.
>>>>
>>>> Is it a problem that "windows equals" is inconsistent with hashCode
>> here? I
>>>> admit these are corner cases.
>>> No, I don't think it is a problem. I was reviewing the invokers of
>>> toLowerCase() and was confused by the wording in the spec. I'm happy
>>> that we should simply lowercase it in a locale independent way, and
>>> don't need to do a "windows equals" implementation.
>>>
>>> Regards,
>>> Tim
>>>
>>
>>
>> --
>> Mohan
>>
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Deven You <de...@gmail.com>.
Hi Mohan,
I have tested the same patch as you, it crashes on drlvm but works well on
j9vm. Please try it. Thanks a lot!
2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
> Hi Deven,
>
> I followed your steps 1 & 2. But java -version crashes with Harmony5.0
>
> Attaching the out file of java -version.
>
> Thanks and Regards,
> Mohan
>
>
> 2010/9/24 Deven You <de...@gmail.com>:
> > I have saw the error before, and I have some investigation of it. I think
> > the root cause is the commit change the class load order. Before this
> > commit, Locale class will be loaded before ULocale class And after this
> > commit, ULocale is loaded before Locale.
> >
> > The direct cause is CharsetProviderImpl no longer use String.toUpperCase,
> > instead it uses its own toUpperCase. And String.toUpperCase calls
> > String.toUpperCase(Locale), this ensure Locale class will be loaded
> before
> > ULocale. However CharsetProviderImpl own toUpperCase uses no Locale, so
> it
> > causes Locale class loaded after ULocale.
> >
> > To solve this problem, a work around could simply be below:
> > 1.Add a Locale static field in String:
> > private static Locale defaulLocale = new Locale.getDefaultLocale();
> > ...
> > 2. Change the String.toUpperCase() from calling
> > toUpperCase(Locale.getDefaultLocale()) to toUpperCase(defaultLocale)
> >
> > above change could solve the NullPointerException mentioned by Mohan, but
> I
> > am not sure if it is a good design.
> >
> > Caused by: java.lang.NullPointerException
> > at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> > at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> > at java.util.Locale.<init>(Locale.java:228)
> > at java.util.Locale.<init>(Locale.java:201)
> > at java.util.Locale.<clinit>(Locale.java:51)
> > at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >
> >
> >
> >
> >
> > 2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
> >
> >> On loading junit.jar[2] i get initialization exception[3]. This
> >> exception disappears if i revert the patch committed for
> >> (HARMONY-6649) toUpper/toLowerCase.
> >>
> >> Make sure your junit.jar contains the signature files[1]. (use the
> >> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
> >> commit, I am not able to load the jar file if it's manifest contains
> >> any signature related files. Any thought on this?
> >>
> >>
> >> [1] jar -tvf junit.jar
> >> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
> >> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
> >> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
> >> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
> >> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
> >> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
> >> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
> >> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
> >> ............
> >>
> >> [2] run command : java -cp junit.jar junit.textui.TestRunner
> >>
> >> [3] Exception:
> >> Uncaught exception in main:
> >> java.lang.ExceptionInInitializerError
> >> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >> at
> >> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
> >> e.java:810)
> >> at
> >> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
> >> e.java:801)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
> >> )
> >> at
> >> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
> >> va:536)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> >> va:144)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> >> va:124)
> >> at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
> >> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
> >> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
> >> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
> >> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
> >> at
> >> java.security.AccessController.doPrivilegedImpl(AccessController.java
> >> :171)
> >> at
> >> java.security.AccessController.doPrivileged(AccessController.java:53)
> >>
> >> at
> java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
> >> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
> >> at java.util.TimeZone.<clinit>(TimeZone.java:91)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
> >> ava:51)
> >> at
> >> org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
> >> 96)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
> >> 0)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
> >> (BerInputStream.java:755)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
> >> eam.java:733)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
> >> eam.java:138)
> >> at
> >> org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
> >> a:140)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
> >> at
> >> org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
> >> entInfo.java:153)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:53)
> >> at
> >> org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
> >> ava:73)
> >> at
> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
> >> at
> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
> >> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
> >> at
> >> java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
> >> :402)
> >> at
> >> java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
> >> 71)
> >> at
> java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
> >> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
> >> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
> >> at
> >> java.security.AccessController.doPrivilegedImpl(AccessController.java
> >> :171)
> >> at
> >> java.security.AccessController.doPrivileged(AccessController.java:64)
> >>
> >> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
> >> at
> >> java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
> >> 0)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
> >> Caused by: java.lang.NullPointerException
> >> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> >> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> >> at java.util.Locale.<init>(Locale.java:228)
> >> at java.util.Locale.<init>(Locale.java:201)
> >> at java.util.Locale.<clinit>(Locale.java:51)
> >> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >> ... 54 more
> >> FAILED to invoke JVM.
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com>
> >> wrote:
> >> > On 24/Sep/2010 06:58, Robert Muir wrote:
> >> >> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com>
> >> wrote:
> >> >>
> >> >>> System.out.println(new File("σ.txt").hashCode());
> >> >>> System.out.println(new File("ς.txt").hashCode());
> >> >>>
> >> >>> prints out
> >> >>>
> >> >>> 889962580
> >> >>> 890776533
> >> >>>
> >> >>> on both Harmony and the RI.
> >> >>>
> >> >>>
> >> >> but perhaps this is just a bug in the RI?
> >> >> according to the link:
> >> >>
> >>
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >> >> <
> >>
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >> >Because
> >> >> equality of abstract pathnames is inherently system-dependent, so is
> the
> >> >> computation of their hash codes.
> >> >>
> >> >> Is it a problem that "windows equals" is inconsistent with hashCode
> >> here? I
> >> >> admit these are corner cases.
> >> >
> >> > No, I don't think it is a problem. I was reviewing the invokers of
> >> > toLowerCase() and was confused by the wording in the spec. I'm happy
> >> > that we should simply lowercase it in a locale independent way, and
> >> > don't need to do a "windows equals" implementation.
> >> >
> >> > Regards,
> >> > Tim
> >> >
> >>
> >>
> >>
> >> --
> >> Mohan
> >>
> >
>
>
>
> --
> Mohan
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Deven You <de...@gmail.com>.
I think below patch can works well, but it is ugly
Please verify it. Thanks a lot!
2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
> Hi Deven,
>
> I followed your steps 1 & 2. But java -version crashes with Harmony5.0
>
> Attaching the out file of java -version.
>
> Thanks and Regards,
> Mohan
>
>
> 2010/9/24 Deven You <de...@gmail.com>:
> > I have saw the error before, and I have some investigation of it. I think
> > the root cause is the commit change the class load order. Before this
> > commit, Locale class will be loaded before ULocale class And after this
> > commit, ULocale is loaded before Locale.
> >
> > The direct cause is CharsetProviderImpl no longer use String.toUpperCase,
> > instead it uses its own toUpperCase. And String.toUpperCase calls
> > String.toUpperCase(Locale), this ensure Locale class will be loaded
> before
> > ULocale. However CharsetProviderImpl own toUpperCase uses no Locale, so
> it
> > causes Locale class loaded after ULocale.
> >
> > To solve this problem, a work around could simply be below:
> > 1.Add a Locale static field in String:
> > private static Locale defaulLocale = new Locale.getDefaultLocale();
> > ...
> > 2. Change the String.toUpperCase() from calling
> > toUpperCase(Locale.getDefaultLocale()) to toUpperCase(defaultLocale)
> >
> > above change could solve the NullPointerException mentioned by Mohan, but
> I
> > am not sure if it is a good design.
> >
> > Caused by: java.lang.NullPointerException
> > at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> > at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> > at java.util.Locale.<init>(Locale.java:228)
> > at java.util.Locale.<init>(Locale.java:201)
> > at java.util.Locale.<clinit>(Locale.java:51)
> > at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >
> >
> >
> >
> >
> > 2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
> >
> >> On loading junit.jar[2] i get initialization exception[3]. This
> >> exception disappears if i revert the patch committed for
> >> (HARMONY-6649) toUpper/toLowerCase.
> >>
> >> Make sure your junit.jar contains the signature files[1]. (use the
> >> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
> >> commit, I am not able to load the jar file if it's manifest contains
> >> any signature related files. Any thought on this?
> >>
> >>
> >> [1] jar -tvf junit.jar
> >> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
> >> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
> >> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
> >> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
> >> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
> >> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
> >> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
> >> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
> >> ............
> >>
> >> [2] run command : java -cp junit.jar junit.textui.TestRunner
> >>
> >> [3] Exception:
> >> Uncaught exception in main:
> >> java.lang.ExceptionInInitializerError
> >> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >> at
> >> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
> >> e.java:810)
> >> at
> >> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
> >> e.java:801)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
> >> )
> >> at
> >> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
> >> va:536)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> >> va:144)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> >> va:124)
> >> at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
> >> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
> >> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
> >> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
> >> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
> >> at
> >> java.security.AccessController.doPrivilegedImpl(AccessController.java
> >> :171)
> >> at
> >> java.security.AccessController.doPrivileged(AccessController.java:53)
> >>
> >> at
> java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
> >> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
> >> at java.util.TimeZone.<clinit>(TimeZone.java:91)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
> >> ava:51)
> >> at
> >> org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
> >> 96)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
> >> 0)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
> >> (BerInputStream.java:755)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
> >> eam.java:733)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
> >> eam.java:138)
> >> at
> >> org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
> >> a:140)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
> >> at
> >> org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
> >> entInfo.java:153)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:53)
> >> at
> >> org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
> >> ava:73)
> >> at
> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
> >> at
> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
> >> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
> >> at
> >> java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
> >> :402)
> >> at
> >> java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
> >> 71)
> >> at
> java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
> >> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
> >> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
> >> at
> >> java.security.AccessController.doPrivilegedImpl(AccessController.java
> >> :171)
> >> at
> >> java.security.AccessController.doPrivileged(AccessController.java:64)
> >>
> >> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
> >> at
> >> java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
> >> 0)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
> >> Caused by: java.lang.NullPointerException
> >> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> >> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> >> at java.util.Locale.<init>(Locale.java:228)
> >> at java.util.Locale.<init>(Locale.java:201)
> >> at java.util.Locale.<clinit>(Locale.java:51)
> >> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >> ... 54 more
> >> FAILED to invoke JVM.
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com>
> >> wrote:
> >> > On 24/Sep/2010 06:58, Robert Muir wrote:
> >> >> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com>
> >> wrote:
> >> >>
> >> >>> System.out.println(new File("�.txt").hashCode());
> >> >>> System.out.println(new File("�.txt").hashCode());
> >> >>>
> >> >>> prints out
> >> >>>
> >> >>> 889962580
> >> >>> 890776533
> >> >>>
> >> >>> on both Harmony and the RI.
> >> >>>
> >> >>>
> >> >> but perhaps this is just a bug in the RI?
> >> >> according to the link:
> >> >>
> >>
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >> >> <
> >>
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >> >Because
> >> >> equality of abstract pathnames is inherently system-dependent, so is
> the
> >> >> computation of their hash codes.
> >> >>
> >> >> Is it a problem that "windows equals" is inconsistent with hashCode
> >> here? I
> >> >> admit these are corner cases.
> >> >
> >> > No, I don't think it is a problem. I was reviewing the invokers of
> >> > toLowerCase() and was confused by the wording in the spec. I'm happy
> >> > that we should simply lowercase it in a locale independent way, and
> >> > don't need to do a "windows equals" implementation.
> >> >
> >> > Regards,
> >> > Tim
> >> >
> >>
> >>
> >>
> >> --
> >> Mohan
> >>
> >
>
>
>
> --
> Mohan
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Deven You <de...@gmail.com>.
Thanks Mark,
Previous build is just in classlib, and I use flow instructions:
svn info
Path: .
URL: https://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1000708
Node Kind: directory
Schedule: normal
Last Changed Author: tellison
Last Changed Rev: 1000708
Last Changed Date: 2010-09-24 13:04:06 +0800 (Fri, 24 Sep 2010)
ant clean
ant
It return above error message.
Then I follow your comments, use
ant clean
ant -Dhy.hdk=/home/deven/hdk_svn/target/hdk/ (which is a complete build
directory on my computer)
it builds successfully! Then I do:
ant clean
ant
It also success. I don't know why and I remembered before I can just use ant
clean; ant in classlib to build the harmony jre in classlib/deploy/jdk/jre.
If there are some changes applied? I think it is better that user can simply
uses ant clean; ant to build the harmony jre in classlib.
2010/9/24 Mark Hindess <ma...@googlemail.com>
>
> In message <AA...@mail.gmail.com>,
> Deven You writes:
> >
> > Hi Mohan,
> > I can not build harmony when update to r1000708. Ant returns below
> errors:
> >
> > -build-native-common:
> > [echo] Making "" in src/main/native/common/unix
> > [exec] cc -DLINUX -DLINUX_X86 -DHYX86 -DIPv6_FUNCTION_SUPPORT
> > -D_REENTRANT -D_FILE_OFFSET_BITS=3D64 -I/home/deven/hy5/deploy/include
> > -I/home/deven/hy5/deploy/jdk/include -I. -I../shared/ -ggdb -O0 -fpic
> > -march=3Dpentium3 -Werror -c -o ../shared/libglob.o
> ../shared/libglob.c
> > [exec] In file included from ../shared/libglob.c:25:
> > [exec] /home/deven/hy5/deploy/include/vmi.h:31:17: error: jni.h: No
> > such file or directory
> >
> > [SNIP]
> >
> > I think your failure may be due to this error.
>
> I don't think so.
>
> Deven, are you building the federated build or just classlib? If just
> classlib, please make sure hy.hdk is pointing to an existing complete build
> of
> the hdk.
>
> Regards,
> Mark.
>
>
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for supplementary characters (HARMONY-6649)
Posted by Mark Hindess <ma...@googlemail.com>.
In message <AA...@mail.gmail.com>,
Deven You writes:
>
> Hi Mohan,
> I can not build harmony when update to r1000708. Ant returns below errors:
>
> -build-native-common:
> [echo] Making "" in src/main/native/common/unix
> [exec] cc -DLINUX -DLINUX_X86 -DHYX86 -DIPv6_FUNCTION_SUPPORT
> -D_REENTRANT -D_FILE_OFFSET_BITS=3D64 -I/home/deven/hy5/deploy/include
> -I/home/deven/hy5/deploy/jdk/include -I. -I../shared/ -ggdb -O0 -fpic
> -march=3Dpentium3 -Werror -c -o ../shared/libglob.o ../shared/libglob.c
> [exec] In file included from ../shared/libglob.c:25:
> [exec] /home/deven/hy5/deploy/include/vmi.h:31:17: error: jni.h: No
> such file or directory
>
> [SNIP]
>
> I think your failure may be due to this error.
I don't think so.
Deven, are you building the federated build or just classlib? If just
classlib, please make sure hy.hdk is pointing to an existing complete build of
the hdk.
Regards,
Mark.
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Deven You <de...@gmail.com>.
Hi Mohan,
I can not build harmony when update to r1000708. Ant returns below errors:
-build-native-common:
[echo] Making "" in src/main/native/common/unix
[exec] cc -DLINUX -DLINUX_X86 -DHYX86 -DIPv6_FUNCTION_SUPPORT
-D_REENTRANT -D_FILE_OFFSET_BITS=64 -I/home/deven/hy5/deploy/include
-I/home/deven/hy5/deploy/jdk/include -I. -I../shared/ -ggdb -O0 -fpic
-march=pentium3 -Werror -c -o ../shared/libglob.o ../shared/libglob.c
[exec] In file included from ../shared/libglob.c:25:
[exec] /home/deven/hy5/deploy/include/vmi.h:31:17: error: jni.h: No
such file or directory
[exec] In file included from /home/deven/hy5/deploy/include/vmi.h:33,
[exec] from ../shared/libglob.c:25:
/home/deven/hy5/deploy/include/hyvmls.h:43: error: expected ‘)’ before ‘*’
token
[exec] /home/deven/hy5/deploy/include/hyvmls.h:44: error: expected ‘;’
before ‘void’
[exec] In file included from ../shared/libglob.c:25:
[exec] /home/deven/hy5/deploy/include/vmi.h:75: error: expected ‘)’
before ‘*’ token
[exec] /home/deven/hy5/deploy/include/vmi.h:102: error: expected ‘)’
before ‘*’ token
[exec] /home/deven/hy5/deploy/include/vmi.h:104: error: expected ‘;’
before ‘JavaVM’
[exec] /home/deven/hy5/deploy/include/vmi.h:128: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘VMI_GetVMIFromJNIEnv’
[exec] /home/deven/hy5/deploy/include/vmi.h:133: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘VMI_GetVMIFromJavaVM’
[exec] In file included from ../shared/libglob.c:25:
[exec] /home/deven/hy5/deploy/include/vmi.h:158: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘CheckVersion’
[exec] /home/deven/hy5/deploy/include/vmi.h:170: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
[exec] /home/deven/hy5/deploy/include/vmi.h:187: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘GetPortLibrary’
[exec] /home/deven/hy5/deploy/include/vmi.h:200: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘GetVMLSFunctions’
[exec] /home/deven/hy5/deploy/include/vmi.h:227: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘GetZipCachePool’
[exec] /home/deven/hy5/deploy/include/vmi.h:244: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
[exec] /home/deven/hy5/deploy/include/vmi.h:258: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘GetSystemProperty’
[exec] /home/deven/hy5/deploy/include/vmi.h:278: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘SetSystemProperty’
[exec] /home/deven/hy5/deploy/include/vmi.h:295: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘CountSystemProperties’
[exec] /home/deven/hy5/deploy/include/vmi.h:313: error: expected ‘=’,
‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘IterateSystemProperties’
[exec] In file included from ../shared/jclglob.h:29,
[exec] from ../shared/libglob.c:26:
[exec] /home/deven/hy5/deploy/include/libglob.h:34: error: expected
‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘JNICALL’
[exec] /home/deven/hy5/deploy/include/libglob.h:35: error: expected
‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ClearLibDetach’
[exec] ../shared/libglob.c:33: error: expected ‘)’ before ‘*’ token
[exec] ../shared/libglob.c:39: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘JNICALL’
[exec] ../shared/libglob.c:83: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘ClearLibDetach’
[exec] ../shared/libglob.c:115: error: expected ‘)’ before ‘*’ token
[exec] make: *** [../shared/libglob.o] Error 1
I think your failure may be due to this error.
2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
> Hi Deven,
>
> I followed your steps 1 & 2. But java -version crashes with Harmony5.0
>
> Attaching the out file of java -version.
>
> Thanks and Regards,
> Mohan
>
>
> 2010/9/24 Deven You <de...@gmail.com>:
> > I have saw the error before, and I have some investigation of it. I think
> > the root cause is the commit change the class load order. Before this
> > commit, Locale class will be loaded before ULocale class And after this
> > commit, ULocale is loaded before Locale.
> >
> > The direct cause is CharsetProviderImpl no longer use String.toUpperCase,
> > instead it uses its own toUpperCase. And String.toUpperCase calls
> > String.toUpperCase(Locale), this ensure Locale class will be loaded
> before
> > ULocale. However CharsetProviderImpl own toUpperCase uses no Locale, so
> it
> > causes Locale class loaded after ULocale.
> >
> > To solve this problem, a work around could simply be below:
> > 1.Add a Locale static field in String:
> > private static Locale defaulLocale = new Locale.getDefaultLocale();
> > ...
> > 2. Change the String.toUpperCase() from calling
> > toUpperCase(Locale.getDefaultLocale()) to toUpperCase(defaultLocale)
> >
> > above change could solve the NullPointerException mentioned by Mohan, but
> I
> > am not sure if it is a good design.
> >
> > Caused by: java.lang.NullPointerException
> > at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> > at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> > at java.util.Locale.<init>(Locale.java:228)
> > at java.util.Locale.<init>(Locale.java:201)
> > at java.util.Locale.<clinit>(Locale.java:51)
> > at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >
> >
> >
> >
> >
> > 2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
> >
> >> On loading junit.jar[2] i get initialization exception[3]. This
> >> exception disappears if i revert the patch committed for
> >> (HARMONY-6649) toUpper/toLowerCase.
> >>
> >> Make sure your junit.jar contains the signature files[1]. (use the
> >> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
> >> commit, I am not able to load the jar file if it's manifest contains
> >> any signature related files. Any thought on this?
> >>
> >>
> >> [1] jar -tvf junit.jar
> >> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
> >> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
> >> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
> >> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
> >> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
> >> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
> >> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
> >> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
> >> ............
> >>
> >> [2] run command : java -cp junit.jar junit.textui.TestRunner
> >>
> >> [3] Exception:
> >> Uncaught exception in main:
> >> java.lang.ExceptionInInitializerError
> >> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >> at
> >> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
> >> e.java:810)
> >> at
> >> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
> >> e.java:801)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
> >> )
> >> at
> >> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
> >> va:536)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> >> va:144)
> >> at
> >> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> >> va:124)
> >> at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
> >> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
> >> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
> >> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
> >> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
> >> at
> >> java.security.AccessController.doPrivilegedImpl(AccessController.java
> >> :171)
> >> at
> >> java.security.AccessController.doPrivileged(AccessController.java:53)
> >>
> >> at
> java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
> >> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
> >> at java.util.TimeZone.<clinit>(TimeZone.java:91)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
> >> ava:51)
> >> at
> >> org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
> >> 96)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
> >> 0)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
> >> (BerInputStream.java:755)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
> >> eam.java:733)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
> >> eam.java:138)
> >> at
> >> org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
> >> a:140)
> >> at
> >> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> >> Stream.java:665)
> >> at
> >> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> >> Stream.java:125)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:48)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
> >> at
> >> org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
> >> entInfo.java:153)
> >> at
> >> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> >> a:53)
> >> at
> >> org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
> >> ava:73)
> >> at
> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
> >> at
> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
> >> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
> >> at
> >> java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
> >> :402)
> >> at
> >> java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
> >> 71)
> >> at
> java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
> >> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
> >> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
> >> at
> >> java.security.AccessController.doPrivilegedImpl(AccessController.java
> >> :171)
> >> at
> >> java.security.AccessController.doPrivileged(AccessController.java:64)
> >>
> >> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
> >> at
> >> java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
> >> 0)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
> >> Caused by: java.lang.NullPointerException
> >> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> >> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> >> at java.util.Locale.<init>(Locale.java:228)
> >> at java.util.Locale.<init>(Locale.java:201)
> >> at java.util.Locale.<clinit>(Locale.java:51)
> >> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> >> ... 54 more
> >> FAILED to invoke JVM.
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com>
> >> wrote:
> >> > On 24/Sep/2010 06:58, Robert Muir wrote:
> >> >> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com>
> >> wrote:
> >> >>
> >> >>> System.out.println(new File("σ.txt").hashCode());
> >> >>> System.out.println(new File("ς.txt").hashCode());
> >> >>>
> >> >>> prints out
> >> >>>
> >> >>> 889962580
> >> >>> 890776533
> >> >>>
> >> >>> on both Harmony and the RI.
> >> >>>
> >> >>>
> >> >> but perhaps this is just a bug in the RI?
> >> >> according to the link:
> >> >>
> >>
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >> >> <
> >>
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >> >Because
> >> >> equality of abstract pathnames is inherently system-dependent, so is
> the
> >> >> computation of their hash codes.
> >> >>
> >> >> Is it a problem that "windows equals" is inconsistent with hashCode
> >> here? I
> >> >> admit these are corner cases.
> >> >
> >> > No, I don't think it is a problem. I was reviewing the invokers of
> >> > toLowerCase() and was confused by the wording in the spec. I'm happy
> >> > that we should simply lowercase it in a locale independent way, and
> >> > don't need to do a "windows equals" implementation.
> >> >
> >> > Regards,
> >> > Tim
> >> >
> >>
> >>
> >>
> >> --
> >> Mohan
> >>
> >
>
>
>
> --
> Mohan
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Mohanraj Loganathan <mo...@gmail.com>.
Hi Deven,
I followed your steps 1 & 2. But java -version crashes with Harmony5.0
Attaching the out file of java -version.
Thanks and Regards,
Mohan
2010/9/24 Deven You <de...@gmail.com>:
> I have saw the error before, and I have some investigation of it. I think
> the root cause is the commit change the class load order. Before this
> commit, Locale class will be loaded before ULocale class And after this
> commit, ULocale is loaded before Locale.
>
> The direct cause is CharsetProviderImpl no longer use String.toUpperCase,
> instead it uses its own toUpperCase. �And String.toUpperCase calls
> String.toUpperCase(Locale), this ensure Locale class will be loaded before
> ULocale. However CharsetProviderImpl own toUpperCase uses no Locale, so it
> causes Locale class loaded after ULocale.
>
> To solve this problem, a work around could simply be below:
> 1.Add a Locale static field in String:
> private static Locale defaulLocale = new Locale.getDefaultLocale();
> ...
> 2. Change the String.toUpperCase() from calling
> toUpperCase(Locale.getDefaultLocale()) to toUpperCase(defaultLocale)
>
> above change could solve the NullPointerException mentioned by Mohan, but I
> am not sure if it is a good design.
>
> Caused by: java.lang.NullPointerException
> � � � at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> � � � at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> � � � at java.util.Locale.<init>(Locale.java:228)
> � � � at java.util.Locale.<init>(Locale.java:201)
> � � � at java.util.Locale.<clinit>(Locale.java:51)
> � � � at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>
>
>
>
>
> 2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
>
>> On loading junit.jar[2] i get initialization exception[3]. This
>> exception disappears if i revert the patch committed for
>> (HARMONY-6649) toUpper/toLowerCase.
>>
>> Make sure your junit.jar contains the signature files[1]. (use the
>> junit.jar(version 3.8.2) bundled with eclipse). �So with HARMONY-6649
>> commit, I am not able to load the jar file if it's manifest contains
>> any signature related files. Any thought on this?
>>
>>
>> [1] jar -tvf junit.jar
>> �9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
>> �9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
>> �3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
>> � � 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
>> � �76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
>> � � 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
>> � � 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
>> � � 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
>> � � �............
>>
>> [2] run command : java -cp junit.jar junit.textui.TestRunner
>>
>> [3] Exception:
>> Uncaught exception in main:
>> java.lang.ExceptionInInitializerError
>> � � � �at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>> � � � �at
>> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
>> e.java:810)
>> � � � �at
>> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
>> e.java:801)
>> � � � �at
>> com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
>> )
>> � � � �at
>> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
>> va:536)
>> � � � �at
>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>> va:144)
>> � � � �at
>> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>> va:124)
>> � � � �at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
>> � � � �at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
>> � � � �at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
>> � � � �at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
>> � � � �at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
>> � � � �at
>> java.security.AccessController.doPrivilegedImpl(AccessController.java
>> :171)
>> � � � �at
>> java.security.AccessController.doPrivileged(AccessController.java:53)
>>
>> � � � �at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
>> � � � �at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
>> � � � �at java.util.TimeZone.<clinit>(TimeZone.java:91)
>> � � � �at
>> org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
>> ava:51)
>> � � � �at
>> org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
>> 96)
>> � � � �at
>> org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
>> 0)
>> � � � �at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> � � � �at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> � � � �at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> � � � �at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> � � � �at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> � � � �at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> � � � �at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> � � � �at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> � � � �at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> � � � �at
>> org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
>> (BerInputStream.java:755)
>> � � � �at
>> org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
>> eam.java:733)
>> � � � �at
>> org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
>> eam.java:138)
>> � � � �at
>> org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
>> � � � �at
>> org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
>> a:140)
>> � � � �at
>> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> � � � �at
>> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> � � � �at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> � � � �at
>> org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
>> � � � �at
>> org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
>> entInfo.java:153)
>> � � � �at
>> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:53)
>> � � � �at
>> org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
>> ava:73)
>> � � � �at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
>> � � � �at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
>> � � � �at java.util.jar.JarFile.getInputStream(JarFile.java:392)
>> � � � �at
>> java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
>> :402)
>> � � � �at
>> java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
>> 71)
>> � � � �at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
>> � � � �at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
>> � � � �at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
>> � � � �at
>> java.security.AccessController.doPrivilegedImpl(AccessController.java
>> :171)
>> � � � �at
>> java.security.AccessController.doPrivileged(AccessController.java:64)
>>
>> � � � �at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
>> � � � �at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
>> � � � �at
>> java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
>> 0)
>> � � � �at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
>> Caused by: java.lang.NullPointerException
>> � � � �at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
>> � � � �at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
>> � � � �at java.util.Locale.<init>(Locale.java:228)
>> � � � �at java.util.Locale.<init>(Locale.java:201)
>> � � � �at java.util.Locale.<clinit>(Locale.java:51)
>> � � � �at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>> � � � �... 54 more
>> FAILED to invoke JVM.
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com>
>> wrote:
>> > On 24/Sep/2010 06:58, Robert Muir wrote:
>> >> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com>
>> wrote:
>> >>
>> >>> System.out.println(new File("�.txt").hashCode());
>> >>> System.out.println(new File("�.txt").hashCode());
>> >>>
>> >>> prints out
>> >>>
>> >>> 889962580
>> >>> 890776533
>> >>>
>> >>> on both Harmony and the RI.
>> >>>
>> >>>
>> >> but perhaps this is just a bug in the RI?
>> >> according to the link:
>> >>
>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>> >> <
>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>> >Because
>> >> equality of abstract pathnames is inherently system-dependent, so is the
>> >> computation of their hash codes.
>> >>
>> >> Is it a problem that "windows equals" is inconsistent with hashCode
>> here? I
>> >> admit these are corner cases.
>> >
>> > No, I don't think it is a problem. �I was reviewing the invokers of
>> > toLowerCase() and was confused by the wording in the spec. �I'm happy
>> > that we should simply lowercase it in a locale independent way, and
>> > don't need to do a "windows equals" implementation.
>> >
>> > Regards,
>> > Tim
>> >
>>
>>
>>
>> --
>> Mohan
>>
>
--
Mohan
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Deven You <de...@gmail.com>.
I have saw the error before, and I have some investigation of it. I think
the root cause is the commit change the class load order. Before this
commit, Locale class will be loaded before ULocale class And after this
commit, ULocale is loaded before Locale.
The direct cause is CharsetProviderImpl no longer use String.toUpperCase,
instead it uses its own toUpperCase. And String.toUpperCase calls
String.toUpperCase(Locale), this ensure Locale class will be loaded before
ULocale. However CharsetProviderImpl own toUpperCase uses no Locale, so it
causes Locale class loaded after ULocale.
To solve this problem, a work around could simply be below:
1.Add a Locale static field in String:
private static Locale defaulLocale = new Locale.getDefaultLocale();
...
2. Change the String.toUpperCase() from calling
toUpperCase(Locale.getDefaultLocale()) to toUpperCase(defaultLocale)
above change could solve the NullPointerException mentioned by Mohan, but I
am not sure if it is a good design.
Caused by: java.lang.NullPointerException
at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
at java.util.Locale.<init>(Locale.java:228)
at java.util.Locale.<init>(Locale.java:201)
at java.util.Locale.<clinit>(Locale.java:51)
at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
2010/9/24 Mohanraj Loganathan <mo...@gmail.com>
> On loading junit.jar[2] i get initialization exception[3]. This
> exception disappears if i revert the patch committed for
> (HARMONY-6649) toUpper/toLowerCase.
>
> Make sure your junit.jar contains the signature files[1]. (use the
> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
> commit, I am not able to load the jar file if it's manifest contains
> any signature related files. Any thought on this?
>
>
> [1] jar -tvf junit.jar
> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
> ............
>
> [2] run command : java -cp junit.jar junit.textui.TestRunner
>
> [3] Exception:
> Uncaught exception in main:
> java.lang.ExceptionInInitializerError
> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> at
> com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
> e.java:810)
> at
> com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
> e.java:801)
> at
> com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
> )
> at
> com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
> va:536)
> at
> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> va:144)
> at
> com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> va:124)
> at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
> at
> java.security.AccessController.doPrivilegedImpl(AccessController.java
> :171)
> at
> java.security.AccessController.doPrivileged(AccessController.java:53)
>
> at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
> at java.util.TimeZone.<clinit>(TimeZone.java:91)
> at
> org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
> ava:51)
> at
> org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
> 96)
> at
> org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
> 0)
> at
> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> Stream.java:665)
> at
> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> Stream.java:125)
> at
> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> a:48)
> at
> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> Stream.java:665)
> at
> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> Stream.java:125)
> at
> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> a:48)
> at
> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> Stream.java:665)
> at
> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> Stream.java:125)
> at
> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> a:48)
> at
> org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
> (BerInputStream.java:755)
> at
> org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
> eam.java:733)
> at
> org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
> eam.java:138)
> at
> org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
> at
> org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
> a:140)
> at
> org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> Stream.java:665)
> at
> org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> Stream.java:125)
> at
> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> a:48)
> at
> org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
> at
> org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
> entInfo.java:153)
> at
> org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> a:53)
> at
> org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
> ava:73)
> at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
> at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
> at
> java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
> :402)
> at
> java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
> 71)
> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
> at
> java.security.AccessController.doPrivilegedImpl(AccessController.java
> :171)
> at
> java.security.AccessController.doPrivileged(AccessController.java:64)
>
> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
> at
> java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
> 0)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
> Caused by: java.lang.NullPointerException
> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> at java.util.Locale.<init>(Locale.java:228)
> at java.util.Locale.<init>(Locale.java:201)
> at java.util.Locale.<clinit>(Locale.java:51)
> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> ... 54 more
> FAILED to invoke JVM.
>
>
>
>
>
>
> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com>
> wrote:
> > On 24/Sep/2010 06:58, Robert Muir wrote:
> >> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com>
> wrote:
> >>
> >>> System.out.println(new File("σ.txt").hashCode());
> >>> System.out.println(new File("ς.txt").hashCode());
> >>>
> >>> prints out
> >>>
> >>> 889962580
> >>> 890776533
> >>>
> >>> on both Harmony and the RI.
> >>>
> >>>
> >> but perhaps this is just a bug in the RI?
> >> according to the link:
> >>
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >> <
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> >Because
> >> equality of abstract pathnames is inherently system-dependent, so is the
> >> computation of their hash codes.
> >>
> >> Is it a problem that "windows equals" is inconsistent with hashCode
> here? I
> >> admit these are corner cases.
> >
> > No, I don't think it is a problem. I was reviewing the invokers of
> > toLowerCase() and was confused by the wording in the spec. I'm happy
> > that we should simply lowercase it in a locale independent way, and
> > don't need to do a "windows equals" implementation.
> >
> > Regards,
> > Tim
> >
>
>
>
> --
> Mohan
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Mohanraj Loganathan <mo...@gmail.com>.
I used following jdk:
Apache Harmony Launcher : (c) Copyright 1991, 2010 The Apache Software Foundatio
n or its licensors, as applicable.
java version "1.5.0"
Apache Harmony (1.5.0)
DRLVM (1.5.0-r1000731)
pre-alpha : not complete or compatible
svn = r1000731, (Sep 24 2010), Windows/ia32/msvc 1310, release build
http://harmony.apache.org
Its very latest one.
Thanks and Regards,
Mohan
On Fri, Sep 24, 2010 at 12:17 PM, Tim Ellison <t....@gmail.com> wrote:
> Hi Mohanraj,
>
> Can you confirm which revision of the code you were running? In
> particular is it >= r1000700 which was the most recent application of
> the patch for this issue?
>
> (I'll be traveling over the next couple of days, so if there is still a
> problem with this patch I'll ask somebody to revert it on my behalf and
> I'll take a closer look when I'm home.)
>
> Regards,
> Tim
>
> On 24/Sep/2010 07:35, Mohanraj Loganathan wrote:
>> On loading junit.jar[2] i get initialization exception[3]. This
>> exception disappears if i revert the patch committed for
>> (HARMONY-6649) toUpper/toLowerCase.
>>
>> Make sure your junit.jar contains the signature files[1]. (use the
>> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
>> commit, I am not able to load the jar file if it's manifest contains
>> any signature related files. Any thought on this?
>>
>>
>> [1] jar -tvf junit.jar
>> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
>> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
>> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
>> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
>> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
>> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
>> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
>> ............
>>
>> [2] run command : java -cp junit.jar junit.textui.TestRunner
>>
>> [3] Exception:
>> Uncaught exception in main:
>> java.lang.ExceptionInInitializerError
>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>> at com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
>> e.java:810)
>> at com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
>> e.java:801)
>> at com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
>> )
>> at com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
>> va:536)
>> at com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>> va:144)
>> at com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
>> va:124)
>> at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
>> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
>> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
>> at java.security.AccessController.doPrivilegedImpl(AccessController.java
>> :171)
>> at java.security.AccessController.doPrivileged(AccessController.java:53)
>>
>> at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
>> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
>> at java.util.TimeZone.<clinit>(TimeZone.java:91)
>> at org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
>> ava:51)
>> at org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
>> 96)
>> at org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
>> 0)
>> at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
>> (BerInputStream.java:755)
>> at org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
>> eam.java:733)
>> at org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
>> eam.java:138)
>> at org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
>> at org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
>> a:140)
>> at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
>> Stream.java:665)
>> at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
>> Stream.java:125)
>> at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:48)
>> at org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
>> at org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
>> entInfo.java:153)
>> at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
>> a:53)
>> at org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
>> ava:73)
>> at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
>> at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
>> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
>> at java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
>> :402)
>> at java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
>> 71)
>> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
>> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
>> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
>> at java.security.AccessController.doPrivilegedImpl(AccessController.java
>> :171)
>> at java.security.AccessController.doPrivileged(AccessController.java:64)
>>
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
>> at java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
>> 0)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
>> Caused by: java.lang.NullPointerException
>> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
>> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
>> at java.util.Locale.<init>(Locale.java:228)
>> at java.util.Locale.<init>(Locale.java:201)
>> at java.util.Locale.<clinit>(Locale.java:51)
>> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
>> ... 54 more
>> FAILED to invoke JVM.
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com> wrote:
>>> On 24/Sep/2010 06:58, Robert Muir wrote:
>>>> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com> wrote:
>>>>
>>>>> System.out.println(new File("σ.txt").hashCode());
>>>>> System.out.println(new File("ς.txt").hashCode());
>>>>>
>>>>> prints out
>>>>>
>>>>> 889962580
>>>>> 890776533
>>>>>
>>>>> on both Harmony and the RI.
>>>>>
>>>>>
>>>> but perhaps this is just a bug in the RI?
>>>> according to the link:
>>>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>>>> <http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29>Because
>>>> equality of abstract pathnames is inherently system-dependent, so is the
>>>> computation of their hash codes.
>>>>
>>>> Is it a problem that "windows equals" is inconsistent with hashCode here? I
>>>> admit these are corner cases.
>>> No, I don't think it is a problem. I was reviewing the invokers of
>>> toLowerCase() and was confused by the wording in the spec. I'm happy
>>> that we should simply lowercase it in a locale independent way, and
>>> don't need to do a "windows equals" implementation.
>>>
>>> Regards,
>>> Tim
>>>
>>
>>
>>
>
--
Mohan
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
Hi Mohanraj,
Can you confirm which revision of the code you were running? In
particular is it >= r1000700 which was the most recent application of
the patch for this issue?
(I'll be traveling over the next couple of days, so if there is still a
problem with this patch I'll ask somebody to revert it on my behalf and
I'll take a closer look when I'm home.)
Regards,
Tim
On 24/Sep/2010 07:35, Mohanraj Loganathan wrote:
> On loading junit.jar[2] i get initialization exception[3]. This
> exception disappears if i revert the patch committed for
> (HARMONY-6649) toUpper/toLowerCase.
>
> Make sure your junit.jar contains the signature files[1]. (use the
> junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
> commit, I am not able to load the jar file if it's manifest contains
> any signature related files. Any thought on this?
>
>
> [1] jar -tvf junit.jar
> 9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
> 9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
> 3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
> 76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
> 0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
> 0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
> 0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
> ............
>
> [2] run command : java -cp junit.jar junit.textui.TestRunner
>
> [3] Exception:
> Uncaught exception in main:
> java.lang.ExceptionInInitializerError
> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> at com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
> e.java:810)
> at com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
> e.java:801)
> at com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
> )
> at com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
> va:536)
> at com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> va:144)
> at com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
> va:124)
> at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
> at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
> at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
> at java.security.AccessController.doPrivilegedImpl(AccessController.java
> :171)
> at java.security.AccessController.doPrivileged(AccessController.java:53)
>
> at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
> at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
> at java.util.TimeZone.<clinit>(TimeZone.java:91)
> at org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
> ava:51)
> at org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
> 96)
> at org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
> 0)
> at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> Stream.java:665)
> at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> Stream.java:125)
> at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> a:48)
> at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> Stream.java:665)
> at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> Stream.java:125)
> at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> a:48)
> at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> Stream.java:665)
> at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> Stream.java:125)
> at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> a:48)
> at org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
> (BerInputStream.java:755)
> at org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
> eam.java:733)
> at org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
> eam.java:138)
> at org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
> at org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
> a:140)
> at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
> Stream.java:665)
> at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
> Stream.java:125)
> at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> a:48)
> at org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
> at org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
> entInfo.java:153)
> at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
> a:53)
> at org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
> ava:73)
> at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
> at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
> at java.util.jar.JarFile.getInputStream(JarFile.java:392)
> at java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
> :402)
> at java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
> 71)
> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
> at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
> at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
> at java.security.AccessController.doPrivilegedImpl(AccessController.java
> :171)
> at java.security.AccessController.doPrivileged(AccessController.java:64)
>
> at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
> at java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
> 0)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
> Caused by: java.lang.NullPointerException
> at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
> at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
> at java.util.Locale.<init>(Locale.java:228)
> at java.util.Locale.<init>(Locale.java:201)
> at java.util.Locale.<clinit>(Locale.java:51)
> at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
> ... 54 more
> FAILED to invoke JVM.
>
>
>
>
>
>
> On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com> wrote:
>> On 24/Sep/2010 06:58, Robert Muir wrote:
>>> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com> wrote:
>>>
>>>> System.out.println(new File("σ.txt").hashCode());
>>>> System.out.println(new File("ς.txt").hashCode());
>>>>
>>>> prints out
>>>>
>>>> 889962580
>>>> 890776533
>>>>
>>>> on both Harmony and the RI.
>>>>
>>>>
>>> but perhaps this is just a bug in the RI?
>>> according to the link:
>>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>>> <http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29>Because
>>> equality of abstract pathnames is inherently system-dependent, so is the
>>> computation of their hash codes.
>>>
>>> Is it a problem that "windows equals" is inconsistent with hashCode here? I
>>> admit these are corner cases.
>> No, I don't think it is a problem. I was reviewing the invokers of
>> toLowerCase() and was confused by the wording in the spec. I'm happy
>> that we should simply lowercase it in a locale independent way, and
>> don't need to do a "windows equals" implementation.
>>
>> Regards,
>> Tim
>>
>
>
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Mohanraj Loganathan <mo...@gmail.com>.
On loading junit.jar[2] i get initialization exception[3]. This
exception disappears if i revert the patch committed for
(HARMONY-6649) toUpper/toLowerCase.
Make sure your junit.jar contains the signature files[1]. (use the
junit.jar(version 3.8.2) bundled with eclipse). So with HARMONY-6649
commit, I am not able to load the jar file if it's manifest contains
any signature related files. Any thought on this?
[1] jar -tvf junit.jar
9714 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/MANIFEST.MF
9791 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.SF
3487 Thu Aug 07 12:04:14 GMT+05:30 2008 META-INF/ECLIPSE.RSA
0 Fri Mar 03 15:22:26 GMT+05:30 2006 META-INF/
76 Thu Aug 07 12:04:08 GMT+05:30 2008 META-INF/eclipse.inf
0 Fri Mar 03 15:22:10 GMT+05:30 2006 junit/
0 Fri Mar 03 15:22:26 GMT+05:30 2006 junit3.8.2/
0 Fri Mar 03 15:22:24 GMT+05:30 2006 junit/awtui/
............
[2] run command : java -cp junit.jar junit.textui.TestRunner
[3] Exception:
Uncaught exception in main:
java.lang.ExceptionInInitializerError
at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
at com.ibm.icu.impl.ICUResourceBundle.instantiateBundle(ICUResourceBundl
e.java:810)
at com.ibm.icu.impl.ICUResourceBundle.getBundleInstance(ICUResourceBundl
e.java:801)
at com.ibm.icu.util.UResourceBundle.getRootType(UResourceBundle.java:489
)
at com.ibm.icu.util.UResourceBundle.instantiateBundle(UResourceBundle.ja
va:536)
at com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
va:144)
at com.ibm.icu.util.UResourceBundle.getBundleInstance(UResourceBundle.ja
va:124)
at com.ibm.icu.impl.ZoneMeta.getSystemTimeZone(ZoneMeta.java:509)
at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:617)
at com.ibm.icu.util.TimeZone.getTimeZone(TimeZone.java:587)
at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:50)
at java.util.SimpleTimeZone$1.run(SimpleTimeZone.java:1)
at java.security.AccessController.doPrivilegedImpl(AccessController.java
:171)
at java.security.AccessController.doPrivileged(AccessController.java:53)
at java.util.SimpleTimeZone.getICUTimeZone(SimpleTimeZone.java:48)
at java.util.SimpleTimeZone.<init>(SimpleTimeZone.java:110)
at java.util.TimeZone.<clinit>(TimeZone.java:91)
at org.apache.harmony.security.asn1.ASN1Time.getDecodedObject(ASN1Time.j
ava:51)
at org.apache.harmony.security.asn1.ASN1UTCTime.decode(ASN1UTCTime.java:
96)
at org.apache.harmony.security.asn1.ASN1Choice.decode(ASN1Choice.java:32
0)
at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
Stream.java:665)
at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
Stream.java:125)
at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
a:48)
at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
Stream.java:665)
at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
Stream.java:125)
at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
a:48)
at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
Stream.java:665)
at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
Stream.java:125)
at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
a:48)
at org.apache.harmony.security.asn1.BerInputStream.decodeValueCollection
(BerInputStream.java:755)
at org.apache.harmony.security.asn1.BerInputStream.readSetOf(BerInputStr
eam.java:733)
at org.apache.harmony.security.asn1.DerInputStream.readSetOf(DerInputStr
eam.java:138)
at org.apache.harmony.security.asn1.ASN1SetOf.decode(ASN1SetOf.java:48)
at org.apache.harmony.security.asn1.ASN1Implicit.decode(ASN1Implicit.jav
a:140)
at org.apache.harmony.security.asn1.BerInputStream.readSequence(BerInput
Stream.java:665)
at org.apache.harmony.security.asn1.DerInputStream.readSequence(DerInput
Stream.java:125)
at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
a:48)
at org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:97)
at org.apache.harmony.security.pkcs7.ContentInfo$1.getDecodedObject(Cont
entInfo.java:153)
at org.apache.harmony.security.asn1.ASN1Sequence.decode(ASN1Sequence.jav
a:53)
at org.apache.harmony.security.utils.JarUtils.verifySignature(JarUtils.j
ava:73)
at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:296)
at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265)
at java.util.jar.JarFile.getInputStream(JarFile.java:392)
at java.net.URLClassLoader$URLJarHandler.createClass(URLClassLoader.java
:402)
at java.net.URLClassLoader$URLJarHandler.findClass(URLClassLoader.java:3
71)
at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1209)
at java.net.URLClassLoader$4.run(URLClassLoader.java:901)
at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
at java.security.AccessController.doPrivilegedImpl(AccessController.java
:171)
at java.security.AccessController.doPrivileged(AccessController.java:64)
at java.net.URLClassLoader.findClass(URLClassLoader.java:903)
at java.lang.ClassLoader.loadClass(ClassLoader.java:488)
at java.lang.ClassLoader$SystemClassLoader.loadClass(ClassLoader.java:87
0)
at java.lang.ClassLoader.loadClass(ClassLoader.java:267)
Caused by: java.lang.NullPointerException
at com.ibm.icu.util.ULocale.getName(ULocale.java:827)
at com.ibm.icu.util.ULocale.<init>(ULocale.java:480)
at java.util.Locale.<init>(Locale.java:228)
at java.util.Locale.<init>(Locale.java:201)
at java.util.Locale.<clinit>(Locale.java:51)
at com.ibm.icu.util.ULocale.<clinit>(ULocale.java:109)
... 54 more
FAILED to invoke JVM.
On Fri, Sep 24, 2010 at 11:57 AM, Tim Ellison <t....@gmail.com> wrote:
> On 24/Sep/2010 06:58, Robert Muir wrote:
>> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com> wrote:
>>
>>> System.out.println(new File("σ.txt").hashCode());
>>> System.out.println(new File("ς.txt").hashCode());
>>>
>>> prints out
>>>
>>> 889962580
>>> 890776533
>>>
>>> on both Harmony and the RI.
>>>
>>>
>> but perhaps this is just a bug in the RI?
>> according to the link:
>> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
>> <http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29>Because
>> equality of abstract pathnames is inherently system-dependent, so is the
>> computation of their hash codes.
>>
>> Is it a problem that "windows equals" is inconsistent with hashCode here? I
>> admit these are corner cases.
>
> No, I don't think it is a problem. I was reviewing the invokers of
> toLowerCase() and was confused by the wording in the spec. I'm happy
> that we should simply lowercase it in a locale independent way, and
> don't need to do a "windows equals" implementation.
>
> Regards,
> Tim
>
--
Mohan
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 24/Sep/2010 06:58, Robert Muir wrote:
> On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com> wrote:
>
>> System.out.println(new File("σ.txt").hashCode());
>> System.out.println(new File("ς.txt").hashCode());
>>
>> prints out
>>
>> 889962580
>> 890776533
>>
>> on both Harmony and the RI.
>>
>>
> but perhaps this is just a bug in the RI?
> according to the link:
> http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
> <http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29>Because
> equality of abstract pathnames is inherently system-dependent, so is the
> computation of their hash codes.
>
> Is it a problem that "windows equals" is inconsistent with hashCode here? I
> admit these are corner cases.
No, I don't think it is a problem. I was reviewing the invokers of
toLowerCase() and was confused by the wording in the spec. I'm happy
that we should simply lowercase it in a locale independent way, and
don't need to do a "windows equals" implementation.
Regards,
Tim
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Sep 24, 2010 at 1:49 AM, Tim Ellison <t....@gmail.com> wrote:
>
> System.out.println(new File("σ.txt").hashCode());
> System.out.println(new File("ς.txt").hashCode());
>
> prints out
>
> 889962580
> 890776533
>
> on both Harmony and the RI.
>
>
but perhaps this is just a bug in the RI?
according to the link:
http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
<http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29>Because
equality of abstract pathnames is inherently system-dependent, so is the
computation of their hash codes.
Is it a problem that "windows equals" is inconsistent with hashCode here? I
admit these are corner cases.
--
Robert Muir
rcmuir@gmail.com
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 24/Sep/2010 06:13, Robert Muir wrote:
> On Fri, Sep 24, 2010 at 1:06 AM, Tim Ellison <t....@gmail.com> wrote:
>
>> On 24/Sep/2010 05:28, Robert Muir wrote:
>>> On Fri, Sep 24, 2010 at 12:10 AM, Tim Ellison <t....@gmail.com>
>> wrote:
>>>> Thanks. Seems strange since it could obviously produce some 'unusual'
>>>> results. In this case, computing a hashCode, it likely doesn't matter
>>>> if the result is a bogus string.
>>>>
>>>>
>>> Do you have an example where the result would be unusual for a filename?
>> I'm not thinking it would be unusual for being interpreted as file path
>> (e.g. it won't introduce a '/' or anything like that) but that the
>> result would not be the lowercase equivalent in the locale that the user
>> created the filename.
>
>
> but case-sensitive filenames (such as windows) don't use locale-dependent
> comparisons?
> they implement locale-independent case-folding. for example if i have a
> file "σ.txt", I cannot create "ς.txt". (I just tried)
> Both of these files are already in lowercase.
Ah ok, I didn't realize that windows did that.
> The interesting question is: how does hashCode() relate? Because a hashcode
> based upon String.toLowerCase(Locale.ENGLISH) would return different
> hashcodes for these two filenames, but with UCharacter.foldCase(), it would
> be the same.
System.out.println(new File("σ.txt").hashCode());
System.out.println(new File("ς.txt").hashCode());
prints out
889962580
890776533
on both Harmony and the RI.
Regards,
Tim
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Sep 24, 2010 at 1:06 AM, Tim Ellison <t....@gmail.com> wrote:
> On 24/Sep/2010 05:28, Robert Muir wrote:
> > On Fri, Sep 24, 2010 at 12:10 AM, Tim Ellison <t....@gmail.com>
> wrote:
> >> Thanks. Seems strange since it could obviously produce some 'unusual'
> >> results. In this case, computing a hashCode, it likely doesn't matter
> >> if the result is a bogus string.
> >>
> >>
> > Do you have an example where the result would be unusual for a filename?
>
> I'm not thinking it would be unusual for being interpreted as file path
> (e.g. it won't introduce a '/' or anything like that) but that the
> result would not be the lowercase equivalent in the locale that the user
> created the filename.
>
>
but case-sensitive filenames (such as windows) don't use locale-dependent
comparisons?
they implement locale-independent case-folding. for example if i have a
file "σ.txt", I cannot create "ς.txt". (I just tried)
Both of these files are already in lowercase.
The interesting question is: how does hashCode() relate? Because a hashcode
based upon String.toLowerCase(Locale.ENGLISH) would return different
hashcodes for these two filenames, but with UCharacter.foldCase(), it would
be the same.
--
Robert Muir
rcmuir@gmail.com
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 24/Sep/2010 05:28, Robert Muir wrote:
> On Fri, Sep 24, 2010 at 12:10 AM, Tim Ellison <t....@gmail.com> wrote:
>> Thanks. Seems strange since it could obviously produce some 'unusual'
>> results. In this case, computing a hashCode, it likely doesn't matter
>> if the result is a bogus string.
>>
>>
> Do you have an example where the result would be unusual for a filename?
I'm not thinking it would be unusual for being interpreted as file path
(e.g. it won't introduce a '/' or anything like that) but that the
result would not be the lowercase equivalent in the locale that the user
created the filename.
> In this case the Unicode standard gives a nice background (in fact,
> filenames are given as the example): see Unicode 5.18, caseless matching:
> http://www.unicode.org/versions/Unicode5.2.0/ch05.pdf
>
> side note: toLowerCase(ENGLISH) isn't exactly the case folding algorithm
> they describe, thats UCharacter.foldCase(String, ...). But its close and the
> idea is the same.
We also lowercase the hostnames passed into SocketPermissions. I'm
guessing we should do those as English too for the same reasons. Today
we lowercase them with the default locale which may give unexpected results.
Regards,
Tim
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Robert Muir <rc...@gmail.com>.
On Fri, Sep 24, 2010 at 12:10 AM, Tim Ellison <t....@gmail.com> wrote:
>
> Thanks. Seems strange since it could obviously produce some 'unusual'
> results. In this case, computing a hashCode, it likely doesn't matter
> if the result is a bogus string.
>
>
Do you have an example where the result would be unusual for a filename?
In this case the Unicode standard gives a nice background (in fact,
filenames are given as the example): see Unicode 5.18, caseless matching:
http://www.unicode.org/versions/Unicode5.2.0/ch05.pdf
side note: toLowerCase(ENGLISH) isn't exactly the case folding algorithm
they describe, thats UCharacter.foldCase(String, ...). But its close and the
idea is the same.
--
Robert Muir
rcmuir@gmail.com
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 24/Sep/2010 03:55, Robert Muir wrote:
> On Thu, Sep 23, 2010 at 10:33 PM, Tim Ellison <t....@gmail.com> wrote:
>
>> So you'll see that I reverted the new String impl until we fix up the
>> possible cases in the boot sequence.
>>
>> I was reviewing the callers of toLowerCase(), and see that
>> File#hashCode() uses that method (not in boot mind you).
>>
>> The Java SE 6 spec for that method [1] has been clarified to add the
>> fact that when lowercasing the pathname on Windows the "Locale is not
>> taken into account on lowercasing the pathname string."
>>
>> Thinking out loud -- so how does that work? How can we lowercase a
>> Unicode string without consideration of a locale?
>>
>>
> if it is not in boot, the easiest way would be to use
> toLowerCase(Locale.ENGLISH).
> While this might seem wrong, documentation on this issue was added in java
> 6.
> "To obtain correct results for locale insensitive strings, use
> toLowerCase(Locale.ENGLISH)."
>
> http://download.oracle.com/javase/6/docs/api/java/lang/String.html#toLowerCase()
Thanks. Seems strange since it could obviously produce some 'unusual'
results. In this case, computing a hashCode, it likely doesn't matter
if the result is a bogus string.
Regards,
Tim
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Robert Muir <rc...@gmail.com>.
On Thu, Sep 23, 2010 at 10:33 PM, Tim Ellison <t....@gmail.com> wrote:
> So you'll see that I reverted the new String impl until we fix up the
> possible cases in the boot sequence.
>
> I was reviewing the callers of toLowerCase(), and see that
> File#hashCode() uses that method (not in boot mind you).
>
> The Java SE 6 spec for that method [1] has been clarified to add the
> fact that when lowercasing the pathname on Windows the "Locale is not
> taken into account on lowercasing the pathname string."
>
> Thinking out loud -- so how does that work? How can we lowercase a
> Unicode string without consideration of a locale?
>
>
if it is not in boot, the easiest way would be to use
toLowerCase(Locale.ENGLISH).
While this might seem wrong, documentation on this issue was added in java
6.
"To obtain correct results for locale insensitive strings, use
toLowerCase(Locale.ENGLISH)."
http://download.oracle.com/javase/6/docs/api/java/lang/String.html#toLowerCase()
--
Robert Muir
rcmuir@gmail.com
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
So you'll see that I reverted the new String impl until we fix up the
possible cases in the boot sequence.
I was reviewing the callers of toLowerCase(), and see that
File#hashCode() uses that method (not in boot mind you).
The Java SE 6 spec for that method [1] has been clarified to add the
fact that when lowercasing the pathname on Windows the "Locale is not
taken into account on lowercasing the pathname string."
Thinking out loud -- so how does that work? How can we lowercase a
Unicode string without consideration of a locale?
[1]
http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%29
Regards,
Tim
On 23/Sep/2010 12:21, Robert Muir wrote:
> On Wed, Sep 22, 2010 at 10:33 PM, Tim Ellison <t....@gmail.com> wrote:
>
>> On 23/Sep/2010 01:10, Robert Muir (JIRA) wrote:
>>> I thought about this too,
>>>
>>> one concern (not knowing if there are more cases involved) would be
>>> if the input "should" be ascii, but "could" be something else. if
>>> String.toLowerCase had the ascii special-case with a fallback to ICU,
>>> it could fail less gracefully in such a situation if it encountered
>>> non-ascii rather than simply not matching, especially since unit
>>> tests tend to have more coverage for the ascii case...
>>>
>>> ...but this might be theoretical
>> Fail less gracefully than what? Today, by using String#toLowerCase(),
>> invalid ascii gets past into ICU so will get converted as though it were
>> a valid char encoding, so I don't think it would make anything worse
>> than it is today.
>>
>
> well, what I meant to say is that the auto-detect idea seems a bit shaky. if
> something wants to do an ascii-only uppercase/lowercase before ICU is
> available, and we know we cannot load ICU yet, then I think the
> toASCIILowerCase is much better than calling String.toLowerCase and saying
> "yeah we know the input is all ascii, it won't load ICU".
>
> The toASCIILowerCase will never load ICU, doesn't depend on an
> implementation detail of String, and then its explicit in the code what is
> going on.
>
>
>> I the the debate is whether to find and fix places in the class library
>> code where we know the input is ascii and change uses of
>> String#toLowercase to use
>> org.apache.harmony.luni.util.Util#toASCIILowerCase() [1]
>>
>
> +1, I think this is the best solution.
>
>
Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
supplementary characters (HARMONY-6649)
Posted by Robert Muir <rc...@gmail.com>.
On Wed, Sep 22, 2010 at 10:33 PM, Tim Ellison <t....@gmail.com> wrote:
> On 23/Sep/2010 01:10, Robert Muir (JIRA) wrote:
> > I thought about this too,
> >
> > one concern (not knowing if there are more cases involved) would be
> > if the input "should" be ascii, but "could" be something else. if
> > String.toLowerCase had the ascii special-case with a fallback to ICU,
> > it could fail less gracefully in such a situation if it encountered
> > non-ascii rather than simply not matching, especially since unit
> > tests tend to have more coverage for the ascii case...
> >
> > ...but this might be theoretical
>
> Fail less gracefully than what? Today, by using String#toLowerCase(),
> invalid ascii gets past into ICU so will get converted as though it were
> a valid char encoding, so I don't think it would make anything worse
> than it is today.
>
well, what I meant to say is that the auto-detect idea seems a bit shaky. if
something wants to do an ascii-only uppercase/lowercase before ICU is
available, and we know we cannot load ICU yet, then I think the
toASCIILowerCase is much better than calling String.toLowerCase and saying
"yeah we know the input is all ascii, it won't load ICU".
The toASCIILowerCase will never load ICU, doesn't depend on an
implementation detail of String, and then its explicit in the code what is
going on.
>
> I the the debate is whether to find and fix places in the class library
> code where we know the input is ascii and change uses of
> String#toLowercase to use
> org.apache.harmony.luni.util.Util#toASCIILowerCase() [1]
>
+1, I think this is the best solution.
--
Robert Muir
rcmuir@gmail.com
[classlib][luni] String.toLowerCase/toUpperCase incorrect for supplementary
characters (HARMONY-6649)
Posted by Tim Ellison <t....@gmail.com>.
On 23/Sep/2010 01:10, Robert Muir (JIRA) wrote:
> I thought about this too,
>
> one concern (not knowing if there are more cases involved) would be
> if the input "should" be ascii, but "could" be something else. if
> String.toLowerCase had the ascii special-case with a fallback to ICU,
> it could fail less gracefully in such a situation if it encountered
> non-ascii rather than simply not matching, especially since unit
> tests tend to have more coverage for the ascii case...
>
> ...but this might be theoretical
Fail less gracefully than what? Today, by using String#toLowerCase(),
invalid ascii gets past into ICU so will get converted as though it were
a valid char encoding, so I don't think it would make anything worse
than it is today.
I the the debate is whether to find and fix places in the class library
code where we know the input is ascii and change uses of
String#toLowercase to use
org.apache.harmony.luni.util.Util#toASCIILowerCase() [1]
or put that detection into String so that ascii doesn't hit ICU.
[1]
http://svn.apache.org/viewvc/harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/org/apache/harmony/luni/util/Util.java?view=markup
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913861#action_12913861 ]
Robert Muir commented on HARMONY-6649:
--------------------------------------
I thought about this too,
one concern (not knowing if there are more cases involved) would be if the input "should" be ascii, but "could" be something else.
if String.toLowerCase had the ascii special-case with a fallback to ICU, it could fail less gracefully in such a situation if it encountered non-ascii rather than simply not matching, especially since unit tests tend to have more coverage for the ascii case...
...but this might be theoretical
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_filepermission.patch, HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913811#action_12913811 ]
Robert Muir commented on HARMONY-6649:
--------------------------------------
I was looking at this failure myself:
Why is java.io.FilePermission.toCanonicalActionString calling String.toLowerCase at all?
it says in its javadocs:
It must be of the form "read,write,execute,delete", all lower case and in the correct order if there is more than one action.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913855#action_12913855 ]
Tim Ellison commented on HARMONY-6649:
--------------------------------------
So there are other places in the class library code that invoke toUpperCase/toLowerCase - so I'm back to wondering if we should be special casing the ascii version in String, and leaving ICU for the more complex cases.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_filepermission.patch, HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913885#action_12913885 ]
Tim Ellison commented on HARMONY-6649:
--------------------------------------
Let's move this conversation to the dev list.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_filepermission.patch, HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910580#action_12910580 ]
Robert Muir commented on HARMONY-6649:
--------------------------------------
Tim, the fix looks good to me. can we fix equalsIgnoreCase here too?
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Attachments: harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914088#action_12914088 ]
Tim Ellison commented on HARMONY-6649:
--------------------------------------
I'll back out the changes to String until we find all the places that need to be fixed in the bootsequence.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_filepermission.patch, HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910144#action_12910144 ]
Tim Ellison commented on HARMONY-6649:
--------------------------------------
Moving the discussion to the dev list
http://markmail.org/message/cfmxbaacmoosripe
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913834#action_12913834 ]
Tim Ellison commented on HARMONY-6649:
--------------------------------------
You snipped the javadoc a bit too selectively.
it says:
" * Returns the string representing this permission's actions. It must be of
* the form "read,write,execute,delete", all lower case and in the correct
* order if there is more than one action.
"
i.e.that's the characteristic of the return string, not the input string which does need to go toLowerCase
But this is going to be ascii.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Mark Hindess (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Hindess reopened HARMONY-6649:
-----------------------------------
This looks like it has broken the hudson builds? https://hudson.apache.org/hudson/view/Harmony/job/Harmony-1.5-head-linux-x86_64-full-tests
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913489#action_12913489 ]
Hudson commented on HARMONY-6649:
---------------------------------
Integrated in Harmony-select-1.5-head-linux-x86_64 #115 (See [https://hudson.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/115/])
Apply regression test for HARMONY-6649 (String.toLowerCase/toUpperCase incorrect for supplementary characters)
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910733#action_12910733 ]
Tim Ellison commented on HARMONY-6649:
--------------------------------------
Yes, but I don't want to forget the regression testcase for this commit.
FYI I'm not going to be around much over the next week, so apologies if progress slows for a while
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Attachments: harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910515#action_12910515 ]
Tim Ellison commented on HARMONY-6649:
--------------------------------------
An improved fix has gone into the LUNI and nio_char modules at repo revision r998030. I'll leave this issue open until I have got some unit tests ready to include, but if you have a chance to look over this fix please send comments.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Attachments: harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Muir updated HARMONY-6649:
---------------------------------
Attachment: HARMONY-6649_tests.patch
here is a proposed patch to the tests:
1. the test for the greek sigma had a bug, it never actually tested sigma in word-final position, only tested it 'isolated'.
2. I added assertions that test supplementary chars for lowercase and uppercase.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Attachments: HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910077#action_12910077 ]
Tim Ellison commented on HARMONY-6649:
--------------------------------------
Yeah, that sounds like a reasonable suggestion.
The existing code in String#toUpperCase(Locale) predates our dependency on ICU, but it may be as simple as replacing the boat-load of code in there with a call to UCharacter.toUppercase(Locale, String)
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913456#action_12913456 ]
Hudson commented on HARMONY-6649:
---------------------------------
Integrated in Harmony-1.5-head-linux-x86_64 #956 (See [https://hudson.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/956/])
Apply regression test for HARMONY-6649 (String.toLowerCase/toUpperCase incorrect for supplementary characters)
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Muir closed HARMONY-6649.
--------------------------------
I tested this, additionally the lucene test case that was failing now passes.
in fact: all of core lucene now passes with harmony!
as for the equalsIgnoreCase, i looked at the javadocs to see what the behavior should be.
According to the javadocs, it seems the existing harmony behavior is correct,
because they explicitly say that equalsIgnoreCase should use toLowerCase(char) and
toUpperCase(char)
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-6649) String.toLowerCase/toUpperCase
incorrect for supplementary characters
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Muir updated HARMONY-6649:
---------------------------------
Attachment: HARMONY-6649_filepermission.patch
Ah Tim, you are right... here's a patch that clears it up for me.
> String.toLowerCase/toUpperCase incorrect for supplementary characters
> ---------------------------------------------------------------------
>
> Key: HARMONY-6649
> URL: https://issues.apache.org/jira/browse/HARMONY-6649
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M15
> Reporter: Robert Muir
> Assignee: Tim Ellison
> Fix For: 5.0M15
>
> Attachments: HARMONY-6649_filepermission.patch, HARMONY-6649_tests.patch, harmony6649.patch
>
>
> Simple testcase:
> {code}
> assertEquals("\uD801\uDC44", "\uD801\uDC1C".toLowerCase());
> {code}
> Looking at modules/luni/src/main/java/java/lang/String.java, the problem is these methods iterate code units (char) not codepoints (int),
> and use Character.toLowerCase(char) and Character.toUpperCase(char), instead of Character.toLowerCase(int), and Character.toUpperCase(int)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.