[
https://issues.apache.org/jira/browse/LUCENE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-2630:
--------------------------------
Attachment: LUCENE-2630_intl.patch
here's a patch for the internationalization differences, since harmony uses ICU.
* the collator gives different order for Locale.US, though
its wierd we test the order of non-US characters under US Locale (its not
defined and inherited from root locale)
I conditionalized this test as such:
{code}
// the sort order of Ø versus U depends on the version of the rules being used
// for the inherited root locale: Ø's order isnt specified in Locale.US since
// its not used in english.
private boolean oStrokeFirst = Collator.getInstance(new
Locale("")).compare("Ø", "U") < 0;
{code}
* the thai dictionary-based break iterator gives different results: I used text
that both impls segment the same way.
> make the build more friendly to apache harmony
> ----------------------------------------------
>
> Key: LUCENE-2630
> URL: https://issues.apache.org/jira/browse/LUCENE-2630
> Project: Lucene - Java
> Issue Type: Task
> Components: Build, Tests
> Affects Versions: 4.0
> Reporter: Robert Muir
> Attachments: LUCENE-2630.patch, LUCENE-2630.patch, LUCENE-2630.patch,
> LUCENE-2630_charutils.patch, LUCENE-2630_intl.patch
>
>
> as part of improved testing, i thought it would be a good idea to make the
> build (ant test) more friendly
> to working under apache harmony.
> i'm not suggesting we de-optimize code for sun jvms or anything crazy like
> that, only use it as a tool.
> for example:
> * bugs in tests/code: for example i found a test that expected ArrayIOOBE
> when really the javadoc contract for the method is just IOOBE... it just
> happens to
> pass always on sun jvm because thats the implementation it always throws.
> * better reproduction of bugs: for example [2 months out of the
> year|http://en.wikipedia.org/wiki/Unusual_software_bug#Phase_of_the_Moon_bug]
> it seems TestQueryParser fails with thai locale in a difficult-to-reproduce
> way.
> but i *always* get similar failures like this with harmony for this test
> class.
> * better stability and portability: we should try (if reasonable) to avoid
> depending
> upon internal details. the same kinds of things that fail in harmony might
> suddenly
> fail in a future sun jdk. because its such a different impl, it brings out
> a lot of interesting stuff.
> at the moment there are currently a lot of failures, I think a lot might be
> caused by this: http://permalink.gmane.org/gmane.comp.java.harmony.devel/39484
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
