lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: IndexInput & GCJ
Date Sat, 02 Oct 2004 20:10:33 GMT

Do you intend to ultimately support Java Lucene with GCJ ?

This would be great as there are several problems with GCJ and Java Lucene 
that I have been maintaining patches for in the PyLucene project 

I'm in the process of upgrading PyLucene to using the just-released Lucene 
1.4.2 and noticed that if I started from the lucene 1.4.2 jar file instead of 
from the lucene 1.4.2 sources many of these patches are no longer necessary.

As a matter of fact, I'm down to 3 patches:

   - GCJH cannot generate a header file from QueryParser.class because there
     are one static field and one static method which have the same name (down
     from two in Lucene 1.4.1)

   - The delete(int) and delete(Term) methods on IndexReader clash with the
     'delete' c++ keyword. GCJ will generate them as 'delete$' which is a neat
     workaround; the problem, however, is that the dynamic linker, at least on
     Mac OS X, doesn't then properly link to these symbols and fails to load
     the resulting shared library.
     So I defined two synonym methods deleteDocument(int) and
     deleteDocuments(Term) in a patch to IndexReader.

   - Because of GCJ bug 15411,, needs to be patched to define the missing method

None of these patches are specific for PyLucene, would you consider 
incorporating them into the Lucene sources ?

The actual patches are included in the attached patches.lucene file.


On Thu, 16 Sep 2004, Doug Cutting wrote:

> I replaced InputStream with IndexInput and BufferedIndexInput, so buffering 
> is now optional.  InputStream is now deprecated and one can also now subclass 
> FSDirectory.
> Still to do:
>  1. Replace OutputStream with IndexOutput and BufferedIndexOutput. This is 
> not critical and mostly for consistency, as mmap makes more sense for 
> read-only data.
>  2. Update RAMDirectory and FSDirectory to no longer use deprecated classes. 
> This is done last, to make sure that the earlier steps to not break 
> back-compatibility for existing Directory implementations.
> Also, I've implemented an mmap-based subclass of FSDirectory in C++ using 
> GCJ.  Any objections to checking this in under src/gcj?  It's not yet much 
> faster than the pure Java implementation, but perhaps it can be made faster, 
> and it also provides an example of how to extend Lucene with C++ in GCJ, 
> which might eventually lead to some big speedups.
> Doug
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
View raw message