questions about Non-bug differences from RI category

[Robert Muir <rc...@gmail.com>]

Hello,

To what extent is the project interested in non-bug differences from RI?

For example, in Lucene we have a test that invokes Character.codePointAt()
and expects an exception.
the javadocs state that it will throw IOOBE (which harmony does),
but the test was written (incorrectly) to expect StringIndexOOBE,
ArrayIndexOOBE (which sun does)

We also see other non-bug differences that match some changes between RI's
versus ICU's internationalization support.
For example, I think the Thai DBBI is different, and there are some
collation differences (i suspect this relates to
HARMONY-5406<https://issues.apache.org/jira/browse/HARMONY-5406>
)

I can open issues for anything we find from our unit tests that aren't
actually bugs in Harmony, if they are of interest.

-- 
Robert Muir
rcmuir@gmail.com

Re: questions about Non-bug differences from RI category

[Robert Muir <rc...@gmail.com>]

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 <rc...@gmail.com> wrote:

>
>
> On Tue, Sep 14, 2010 at 12:06 PM, Tim Ellison <t....@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

Re: questions about Non-bug differences from RI category

[Mark Hindess <ma...@googlemail.com>]

In message <AA...@mail.gmail.com>,
Robert Muir writes:
>
> On Tue, Sep 14, 2010 at 12:06 PM, Tim Ellison <t....@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.

Robert opened HARMONY-6648 and I committed a fix for it at r997081.
-Mark.

Re: questions about Non-bug differences from RI category

[Robert Muir <rc...@gmail.com>]

On Tue, Sep 14, 2010 at 12:06 PM, Tim Ellison <t....@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

Re: questions about Non-bug differences from RI category

[Tim Ellison <t....@gmail.com>]

On 14/Sep/2010 16:39, Robert Muir wrote:
> To what extent is the project interested in non-bug differences from RI?

All are interesting, either as differences we will fix, or as
documentation of decisions not to fix.

> For example, in Lucene we have a test that invokes Character.codePointAt()
> and expects an exception.
> the javadocs state that it will throw IOOBE (which harmony does),
> but the test was written (incorrectly) to expect StringIndexOOBE,
> ArrayIndexOOBE (which sun does)

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.

> We also see other non-bug differences that match some changes between RI's
> versus ICU's internationalization support.
> For example, I think the Thai DBBI is different, and there are some
> collation differences (i suspect this relates to
> HARMONY-5406<https://issues.apache.org/jira/browse/HARMONY-5406>
> )

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.

> I can open issues for anything we find from our unit tests that aren't
> actually bugs in Harmony, if they are of interest.

Yes, please continue to discuss them here.  As you can see, I think it
requires a debate as to which we would fix; e.g. if people agree that
the i18n is not something we want to pursue then having a non-bug
difference is useful as a record of that decision.

Regards,
Tim