lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Williams <>
Subject Re: A proper port of Lucene to C#
Date Fri, 03 Jun 2005 14:30:35 GMT
Antonello Provenzano wrote:

> Erik Hatcher ha scritto:
>> On Jun 3, 2005, at 4:53 AM, Antonello Provenzano wrote:
>>> I'm quite finishing the porting (a *proper* one) of the Apache  
>>> Jakarta project Lucene.
>> What version of Lucene did you port?  How can you ever be "finished"  
>> since Lucene is continually evolving?
> I'm porting the version 1.4.3. I'm a developer as you are: I know 
> perfectly a software is always in-motion and cannot finish until it's 
> discontinued!
>>> and would like it to be hosted and mantained: I have no time for  
>>> the development of the code. .
I have recently tested yet another technique for using Lucene in .Net 
that resolves these two problems and others.  I.e., with no effort I can 
use the latest Java source code pulled from subversion, including all 
patches in bugzilla.  Also, it is possible to submit patches back to the 
main java codeline.  The approach is to use IKVM for byte-code 
translation, leaving the source in Java.  I tried this in both Microsoft 
.Net and Mono.  On the Microsoft platform, all unit tests passed except 
for TestDateTools (and DateTools are only used by apps, not directly by 
Lucene itself).  The bug there turned out to be an issue in the Calendar 
class in GNU.Classpath.  I reported this and the Classpath guys have 
fixed it, so as soon as the fix propagates to IKVM, all unit tests will 

In Mono however, many tests fail.  I think many bugs remain in Mono.

I've not done stress testing yet, but performance on the unit test suite 
seems faster than in Java.  Running the unit tests requires JUnit, which 
ikvm's into .Net byte code without issue.

There are disadvantages to this approach as well, but the advantages of 
access to latest code, zero effort, and participation in the Java Lucene 
community are strong positives.  Integration with Lucene from C#.Net is 
not quite as good as the source code ports, e.g. names remain in Java 
conventions, but otherwise integration is fairly seamless.  The main 
disadvantages are with debugging (e.g., can't step into Lucene from 
C#.Net app in Visual Studio) and with reverse integration (can't easily 
code a call from Lucene, e.g. a patch, into C#; it is possible to 
subclass Lucene in C#).  If one does Lucene patches and extensions in 
Java, all works well.  Plus, that allows for contributing them back to 
the main codeline.

> Ok... I pourposed the port to the #Dashboard community, being a Mono 
> developer: they suggested me to pourpose it to the Lucene community 
> too, saying you would be interested in hosting it.

Antonello, have you run the unit tests on your port in Mono?  If that 
works, it would be a most exciting development.  Is your code posted 

> Anyway, the #Dashboard developers would be interested in the development.

Can you provide a pointer to these guys?

> The implementation I downloaded and compared against is the dotLucene 
> (used by #dashboard and beagle too): I was unable to find the source 
> code for the George Aroush's Lucene.NET. Then, I contacted the author 
> of the dotLucene project, for replacing his code with mine. I'm still 
> waiting for an answer...

George has many tools that help to automate his port.  Also, he has just 
completed an initial port of the latest 1.9 code base, which some of us 
need.  What porting approach do you use -- how much manual effort is 


View raw message