Re: New FieldSortedHitQueue uses Java 1.4 feature

[Dmitry Serebrennikov]

Jamie M wrote:

--- Jamie M <[EMAIL PROTECTED]> wrote:
 

--- Doug Cutting <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]