lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] Resolved: (LUCENE-2630) make the build more friendly to apache harmony
Date Wed, 22 Sep 2010 05:55:32 GMT


Robert Muir resolved LUCENE-2630.

         Assignee: Robert Muir
    Fix Version/s: 3.1
       Resolution: Fixed

happy to mark this one resolved: harmony devs have quickly fixed issues we found.

with r999725 of harmony, all core, contrib, modules tests pass for both trunk and 3x on harmony
(with the exception of contrib/remote due to rmic problems)

> 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
>            Assignee: Robert Muir
>             Fix For: 3.1, 4.0
>         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