lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] Updated: (LUCENE-2630) make the build more friendly to apache harmony
Date Tue, 14 Sep 2010 19:09:39 GMT


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:
  // 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") <
* 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:
>             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,
> 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|]
>   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 message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message