harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: questions about Non-bug differences from RI category
Date Tue, 14 Sep 2010 20:57:26 GMT
Just as a followup, I looked into this collation difference.

for Lucene, the difference between the ICU/Harmony implementation and the RI
implementation can be seen here:

Collator.getInstance(new Locale("")).compare("Ø", "U")

So I think this is covered under differences in CLDR data (HARMONY-5406),
since its differences in Collation rules for the root Locale.

On Tue, Sep 14, 2010 at 12:12 PM, Robert Muir <rcmuir@gmail.com> wrote:

>
>
> On Tue, Sep 14, 2010 at 12:06 PM, Tim Ellison <t.p.ellison@gmail.com>wrote:
>
>>
>> A quick look at the harmony code, and it seems we are explicitly
>> throwing IIOBE's from our code, e.g.
>>
>>  if (index < 0 || index >= len) {
>>      throw new IndexOutOfBoundsException();
>>  }
>>
>> In this case I see no reason why we wouldn't match the RI behavior, even
>> though it is not required by the spec.
>>
>
> OK , I can open a jira issue for this one.
>
>
>>
>> Yes, again I think this beyond the spec.  As you say, Harmony defers to
>> the ICU project to provide the i18n functionality.  If you consider the
>> collation or break iterators to be producing a result that is 'wrong'
>> we'd raise it with ICU and get their opinion.
>>
>>
> Yes, in both cases Lucene supports "jdk or icu" impl for collation and
> break iteration, so we have encountered these differences before.
> I can't comment on the collation difference (except we already
> conditionalized our test case for ICU here)
> For the break iterator difference, a user from Laos commented that when he
> uses the ICU implementation with Thai, he gets better results... so maybe
> ICU simply improved the thai dictionary?
>
> --
> Robert Muir
> rcmuir@gmail.com
>



-- 
Robert Muir
rcmuir@gmail.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message