lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <a...@osafoundation.org>
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 
(http://pylucene.osafoundation.org).

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,
     http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15411,
     Searcher.java needs to be patched to define the missing method
     definitions

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.

Andi..


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