lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Serebrennikov <dmit...@earthlink.net>
Subject Re: New FieldSortedHitQueue uses Java 1.4 feature
Date Wed, 03 Mar 2004 22:30:46 GMT
Jamie M wrote:

>--- Jamie M <jamienz@yahoo.com> wrote:
>  
>
>>--- Doug Cutting <cutting@apache.org> wrote:
>>    
>>
>>>Eric Isakson wrote:
>>>      
>>>
>>>>I hadn't heard any discussion about bumping up
>>>>        
>>>>
>>to
>>    
>>
>>>Java 1.4 in the Lucene 1.4 release. Was this just
>>>overlooked or are we planning to drop support for
>>>pre 1.4 JVMs?
>>>
>>>There hasn't been any discussion yet, so, by
>>>default, we should still 
>>>try to make things work in Java 1.2.
>>>
>>>That said, maybe we should have such a discussion.
>>>      
>>>
>>>Folks have been 
>>>encountering strange bugs using Lucene in Java 1.3
>>>recently.  There are 
>>>some features of Java 1.4 which could be useful,
>>>e.g., LinkedHashMap, 
>>>for easy implementation of LRU caches, regex
>>>support, logging, xml 
>>>parsers, etc.  So there are good reasons to move
>>>      
>>>
>>to
>>    
>>
>>>1.4.
>>>
>>>Are there reasons not to move to 1.4?  1.4 has
>>>      
>>>
>>been
>>    
>>
>>>out for two years 
>>>now, and is pretty stable, but perhaps there are
>>>reasons some folks are 
>>>still unable to use it.  If so, please speak up.
>>>
>>>Doug
>>>      
>>>
>>I'd be in support of moving to 1.4 if I wasn't
>>developing for WebSphere.  IBM's WebSphere 4 is in
>>very wide use and uses 1.3.1.  
>>
>>However, I've already worked around the regexp stuff
>>in FieldSortedHitQueue by replacing it with
>>Integer.parseInt(..) and Float.parseFloat(..),
>>removing the 1.4 depenency. i.e, replaced:
>>
>>if (pIntegers.matcher(termtext).matches())
>>    return IntegerSortedHitQueue.comparator (reader,
>>enumerator, field);
>>
>>else if (pFloats.matcher(termtext).matches())
>>    return FloatSortedHitQueue.comparator (reader,
>>enumerator, field);
>>
>>with:
>>
>>try {
>>   int i = Integer.parseInt(termtext);
>>   return IntegerSortedHitQueue.comparator (reader,
>>enumerator, field);
>>} catch (NumberFormatException e) {}
>>
>>try {
>>    float f = Float.parseFloat(termtext);
>>    return FloatSortedHitQueue.comparator (reader,
>>enumerator, field);
>>} catch (NumberFormatException e) {}
>>
>>
>>regards,
>>
>>jamie
>>
>>    
>>
>
>
>What I said above about continuing to support JDK 1.3,
>and in my case WebSphere 4's 1.3.1 JDK, is actually a
>bit redundant since the current code in cvs throws a
>"java.io.IOException: read past EOF" exception when
>building an index under this
>environment(http://issues.apache.org/bugzilla/show_bug.cgi?id=27408)
>
>This is due to a bug in IBM's 1.3.1 JDK, exposed by
>the recent .tis file change.
>
>So, I'll change my vote to neutral, since lucene 1.4
>is already not supported by my JDK 1.3 environment,
>with or without the FieldSortedHitQueue regexp stuff.
>
>jamie
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Search - Find what you’re looking for faster
>http://search.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
>
>  
>
The change you made from Regexp to Integer.parseInt sounds like the 
right way to go anyway. Why pay the overhead of the regexp processing if 
all that's needed is a simple parsing already supported elsewhere.

Dmitry.



---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


Mime
View raw message