[jira] Updated: (LUCENE-2630) make the build more friendly to apache harmony

["Robert Muir (JIRA)" <ji...@apache.org>]

     [ 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.patch

here's a patch that allows things to compile and tests to run

* removed the sunisms from the compile task so it works with harmony in the expected way:  (-Dbuild.compiler=extJavac)
* simplified MockTokenizer.SIMPLE, most tests use whitespace anyway and the humongous regexp was really unnecessary.
* fixed the IOOBE thing in CharacterUtils.

there are more things that should be fixed, but i'd like to commit this so that its at least possible to compile and run test.

> 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
>
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org