Home | About | Sematext search-lucene.com search-hadoop.com
 Search Lucene and all its subprojects:

Switch to Threaded View
Lucene.Net, mail # dev - AW: Lucene.NET Community Status


Copy link to this message
-
AW: Lucene.NET Community Status
Andreas Mummenhoff 2010-11-02, 18:01
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:[EMAIL PROTECTED]]
Gesendet: Dienstag, 2. November 2010 16:13
An: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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.