[ 
https://issues.apache.org/jira/browse/LUCENE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905064#action_12905064
 ] 

Robert Muir commented on LUCENE-2630:
-------------------------------------

{quote}
Robert, I wonder if we really still need CharacterUtils in 4.0 - we don't have 
to guarantee any bwcompat on the TokenFilter / Tokenizer level and we should 
not have any problems with different lowercase methodes etc. Maybe we should 
move the codepoint aware reader code out to another class or clean that one up?
{quote}

I'd rather discuss this (dropping 2.x analyzer backwards compatibility/Version) 
on another jira issue to keep this one simple :)


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

Reply via email to