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
