I think IKVM already is a way, it's already working, so everybody can download IKVM and use it together with Lucene. But there is still a big need for Lucene.Net, it's a big difference if you have a native solution or a "monster" with foreign classes, because the whole java-runtime is also translated to IL.
We should continue working on the automated way, has anybody tried the others, http://www.artinsoft.com/so_j2ee.aspx, and http://sourceforge.net/projects/j2cstranslator/ ? If I investigate my results further, I can find the following: A) TODO TASK Anonymous inner classes are not converted to .NET: 52 52 cases, to much - has somebody an idea? Maybe something with private classes and auto generated class names? B) TODO TASK C# does not allow fall-through from a non-empty 'case': 1 one case, manual correction is easy C) TODO TASK Enums cannot contain methods in .NET: 1 one case, manual correction is easy D) TODO TASK Interfaces cannot contain fields in .NET: 54 too much, should be converted to abstract classes E) TODO TASK Interfaces cannot contain types in .NET: 10 same as D) F) TODO TASK Java wildcard generics are not converted to .NET: 29 too much, no idea G) TODO TASK Local classes are not converted by Java to VB & C# Converter: 2 maybe same solution as A)? H) TODO TASK Most Java annotations will not have direct .NET equivalent attributes: 12 no idea, but 12 cases are not so much I) TODO TASK Octal literals cannot be represented in C#: 13 easy to translate manually J) TODO TASK The following line could not be converted: 1 only one case K) TODO TASK There is no .NET Dictionary equivalent to the Java 'entrySet' method: 18 provide a custom Dictionary class L) TODO TASK There is no .NET Dictionary equivalent to the Java 'putAll' method: 4 same as K) M) TODO TASK There is no .NET LinkedList equivalent to the Java 'remove' method: 1 same as K) N) TODO TASK There is no '>>>' operator in .NET: 25 no idea, O) WARNING 'final' parameters are not allowed in .NET: 155 can be ignored P) WARNING Method 'throws' clauses are not available in .NET: 1266 can be ignored Q) WARNING The original Java variable was marked 'final': 653 can be ignored R) WARNING Unlike Java's ListIterator, enumerators in .NET do not allow altering the collection: 2. only 2 cases I think there is hope to solve most things in one or the other way, so that maybe 1 week work is left after the automatic conversion. This should be a great win. -----Ursprüngliche Nachricht----- Von: digy digy [mailto:digyd...@gmail.com] Gesendet: Dienstag, 2. November 2010 16:13 An: lucene-net-u...@lucene.apache.org Betreff: Re: Lucene.NET Community Status See previous discussions about IKVM http://comments.gmane.org/gmane.comp.jakarta.lucene.net.user/806 http://comments.gmane.org/gmane.comp.jakarta.lucene.net.user/802 DIGY On Tue, Nov 2, 2010 at 4:58 PM, Hans Merkl <h...@hmerkl.com> wrote: > Has anybody tried using Lucene with IKVM.NET? I haven't tried it myself > (yet) but I keep hearing it works pretty well. That way, there would ne no > need for porting the actual code, instead you just convert the Java > executables to .NET. If it works, it seems a much faster approach than > porting the source code. > > On Tue, Nov 2, 2010 at 09:55, Wyatt Barnett <wyatt.barn...@gmail.com> > wrote: > > > Not sure if this is the right way to volunteer, but I've got limited > > experience with Lucene but it has been the best thing since sliced > > bread to me and I'd love to contribute to the project in any way I > > can. > > > > I'll also add that I've been running a home-compiled version of the > > 2.9.2 branch in production for the last few months with no problems, > > so I think it wouldn't take much to push that as a new binary release. > > > > While I've got the floor, I'm also definitely down with the suggestion > > for a .NET ethos friendly wrapper -- could help the cause quite a bit > > by making this much more approachable for the rest of the .NET world. > > >