lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Mummenhoff" <>
Subject AW: Lucene.NET Community Status
Date Mon, 01 Nov 2010 22:26:14 GMT
Hi Digy,

maybe you know db4o, which is available for Java and .Net. As far as I know,
the development is done in Java and the .Net port is done with an automated
tool. I don't know if it's public available, one thing I found is
Anyway, it's for sure that they maintain only one code base and generate the
.Net version from the java code, which is even quite .Netified. So it must
be possible to do automated conversion!!!

There is also another project on sourceforge that allows to translate java
to c#:

Another tool I found is

I know another product of this company, Instant C# / Instant VB, which do a
very good job.

And of course we can look into, which
was proposed from George Aroush.

Maybe the afford is worth trying to get an automated tool running (for
example taking j2cs and tweak it to support special Lucene-cases). So the
next step could be to work not on Lucene.Net directly, but developing an
automated translation process. This in turn could open the future for other
wishes (for example translating setXXX, getXXX into properties).

What do you think?

And if there is some resistance with commercial tools, I could donate some
money for the license, and I'm sure other's will do as well, so a few
hundred $ will not be the problem.


-----Urspr√ľngliche Nachricht-----
Von: Digy [] 
Gesendet: Montag, 1. November 2010 22:32
Betreff: RE: Lucene.NET Community Status

Simply "No" for all your question. I have no tools for automating this

> How does NHibernate and other .NET ports handle this?
Good question :)


-----Original Message-----
From: Phil Haack [] 
Sent: Monday, November 01, 2010 11:12 PM
Subject: RE: Lucene.NET Community Status

Hi Digy,

I saw George Aroush's response on what it takes to do the port. I didn't
realize how much effort it was to just get the port working. Hypothetically
speaking, are there code translators that do a good enough job of porting
the code where there would be time to spend on a tiny bit of clean up to
.NET idioms?  That way, for each major version, you do the port and then do
a tiny bit of cleanup. Forgive my ignorance in this area.

How does NHibernate and other .NET ports handle this?

Trying to understand the logic and rewrite in .NET seems like a gargantuan
task. I'm certainly no search expert and am not up to the task. ;) However,
what automated test coverage do you have. Is it pretty substantial? Is it
possible to run the Java Lucene tests against the .NET code? I ask because
at the very least, a small amount of deviation form the line by line would
be mitigated by such tests.


-----Original Message-----
From: Digy [] 
Sent: Monday, November 01, 2010 2:02 PM
Subject: RE: Lucene.NET Community Status

Hi Phil,

I see your point, but there is no easy "hybrid" way.
What would you do if you wanted to port a new version of java code?
* Searching for differences from the current version and trying to apply
those changes to the current code Or
* Trying to understand the logic and rewrite the code

The 2nd approach needs a great community as does.
The 1st one needs a "similar" code to "see" the differences easily(I haven't
found an automated way).


-----Original Message-----
From: Phil Haack []
Sent: Monday, November 01, 2010 10:26 PM
Subject: Lucene.NET Community Status

Hi All,

Sorry to jump in the middle of a conversation like this, but I've read the
thread on this and wanted to point out a couple of things in the hopes of
being more helpful than not :)

The goal of Lucene.NET has in the past been to be a line by line port of
Lucene for the following reason posited by Robert Jordan
/raw/%3Ciam8c3$d6g$ He says:

> You're missing the point. Lucene.NET is "just" a port of Lucene With a 
> .NET-like API. The searching expertise is still there where it
> belongs: to the main Lucene project. If you want "new approaches in 
> search" then you're looking at the wrong project.

As Jeff Rodenburg (a former committer) points out, the reason for this
approach was

> keeping the Lucene.Net codebase on par line-by-line with the 
> Java-based project would facilitate easier maintenance of the codebase
> time; as the Java version received improvements, one could implement 
> the same in C#, and the project would benefit all the same.

But it seems to me the very fact we're even having this conversation at all
(and given the fact that.NET implementation is far behind the Java
implementation) shows that this strategy isn't working. At least not in its
current form.

But we can't discount the importance and magnitude of Robert's point. The
Java Lucene community is and will continue to do the heavy lifting when it
comes to search expertise. Thus I see the benefits of staying true to some
degree to the Lucene codebase. But I wonder if some carefully targeted
divergence could help breathe new life into the project. Perhaps some sort
of hybrid approach that loosens this line by line requirement? Some have
mentioned having the internals be closer to the line-by-line but the public
surface area fit more .NET. Even parts of the internals could be .NETified
to a small degree as long as it's clear where the original source was from
and with sufficient test automation.

After all, the project is *already* not keeping up with the Java version.
Perhaps by making the library more ".NET Friendly", the extra cost to do the
port is more than outweighed by the extra involvement of people who want to
see the project stay alive.

I'm pretty swamped with my other OSS projects, but Lucene.NET is important
to me personally so I would like to help in any way I can.


View raw message