lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Mummenhoff" <an...@online.de>
Subject WG: Lucene.NET Community Status
Date Tue, 02 Nov 2010 13:03:24 GMT
I tried Java to VB & C# Converter (Version 1.5, which I have, current
version is 2.1), the conversion took me about 1 minute, the converted files
were commented with the following number of issues:

What		Comment
Count
TODO TASK	Anonymous inner classes are not converted to .NET:
52
TODO TASK	C# does not allow fall-through from a non-empty 'case':
1
TODO TASK	Enums cannot contain methods in .NET:
1
TODO TASK	Interfaces cannot contain fields in .NET:
54
TODO TASK	Interfaces cannot contain types in .NET:
10
TODO TASK	Java wildcard generics are not converted to .NET:
29
TODO TASK	Local classes are not converted by Java to VB & C#
Converter:		2
TODO TASK	Most Java annotations will not have direct .NET equivalent
attributes:	12
TODO TASK	Octal literals cannot be represented in C#:
13
TODO TASK	The following line could not be converted:
1
TODO TASK	There is no .NET Dictionary equivalent to the Java
'entrySet' method:	18
TODO TASK	There is no .NET Dictionary equivalent to the Java 'putAll'
method:	4
TODO TASK	There is no .NET LinkedList equivalent to the Java 'remove'
method:	1
TODO TASK	There is no '>>>' operator in .NET:
25
WARNING	'final' parameters are not allowed in .NET:
155
WARNING	Method 'throws' clauses are not available in .NET:
1266
WARNING	The original Java variable was marked 'final':
653
WARNING	Unlike Java's ListIterator, enumerators in .NET do not allow
altering the collection:	2.







-----Urspr√ľngliche Nachricht-----
Von: Michael Mitiaguin [mailto:mitiaguin@gmail.com] 
Gesendet: Dienstag, 2. November 2010 00:56
An: lucene-net-user@lucene.apache.org
Betreff: Re: Lucene.NET Community Status

Since some folks expressed a desire to help, perhaps, they could grab ( with
mentioning to the group - to avoid the same work ;  however,  it is possible
that  people may come to slightly different conclusions)  various
cross-translators and report results  to the group.   The main interest, I
suppose, conversion Java Lucene 3.0.2 which is Java 1.5 and, I believe, JCLA
is just not  capable to swallow. For the rest it remains to be seen if
results are adequate for further refinement. If not, there is a problem ( or
stumbling block ) how to keep up with Java Lucene.

On Tue, Nov 2, 2010 at 10:12 AM, Ben Martz <benmartz@gmail.com> wrote:

> I'm glad that my previous email appears to not have gone through since at
> first glance this solution appears to be much more mature that what I have
> been looking at. Thanks for the links guys.
>
>
> Igor Latyshev wrote:
>
>>
>> Sharpen from db4o seems to be an open source tool:
>>
>> http://developer.db4o.com/Blogs/Product/tabid/167/entryid/94/Default.aspx
>>
>> (there's a link to source code repository at the bottom of the page)
>>
>> Igor
>>
>> On 01/11/2010 22:37, Phil Haack wrote:
>>
>>> Anyone know which translator does the best job? Perhaps we should decide
>>> which is our preferred tool for translation (maybe with a #2 and #3
backup)
>>> and if cost is an issue, we can tackle that together. It seems to me
that
>>> helping out with the cost is something that a foundation ought to help
with.
>>> :) But if the Apache foundation doesn't pony up the money for the
software,
>>> maybe we can ask around. I'd be happy to see if I know any companies
that
>>> can help with sponsorship to purchase a license for such software.
>>>
>>> Phil
>>>
>>> -----Original Message-----
>>> From: Nic Wise [mailto:nicw@fastchicken.co.nz]
>>> Sent: Monday, November 01, 2010 3:32 PM
>>> To: lucene-net-user@lucene.apache.org; anmum@online.de
>>> Cc: lucene-net-dev@lucene.apache.org
>>> Subject: Re: Lucene.NET Community Status
>>>
>>> Damn, you bet me to it. I was just about to post the same thing.
>>>
>>> http://foodformonkeys.blogspot.com/2010/10/ngit.html
>>>
>>> It was used here (recently - over the weekend I think) to port JGit into
>>> NGit
>>>
>>> I'd stick my hand up - having use Lucene.Net on projects from
>>> multi-million dollar packaged products (Quest Archive Manager) to
websites (
>>> www.topgear.com) and various other places - but I'm about to leave on a
>>> 3 month trip away, with limited internet for a lot of it....  So I'll
have
>>> to see where things are when I get back...
>>>
>>>
>>> On Mon, Nov 1, 2010 at 22:26, Andreas Mummenhoff<anmum@online.de>
>>>  wrote:
>>>
>>>> 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
>>>> (http://developer.db4o.com/Projects/html/projectspaces/db4o_product_de
>>>> sign/s
>>>> harpen.html).
>>>> 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#:
>>>>
>>>> http://sourceforge.net/projects/j2cstranslator/
>>>>
>>>>
>>>> Another tool I found is
>>>>
>>>> http://tangiblesoftwaresolutions.com/Product_Details/Java_to_VB_and_CS
>>>> harp_C
>>>> onverter_Details.html
>>>>
>>>> I know another product of this company, Instant C# / Instant VB, which
>>>> do a very good job.
>>>>
>>>> And of course we can look into http://www.artinsoft.com/so_j2ee.aspx,
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>> Andreas
>>>>
>>>>
>>>> -----Urspr√ľngliche Nachricht-----
>>>> Von: Digy [mailto:digydigy@gmail.com]
>>>> Gesendet: Montag, 1. November 2010 22:32
>>>> An: lucene-net-user@lucene.apache.org
>>>> Betreff: RE: Lucene.NET Community Status
>>>>
>>>> Simply "No" for all your question. I have no tools for automating this
>>>> process.
>>>>
>>>>  How does NHibernate and other .NET ports handle this?
>>>>>
>>>> Good question :)
>>>>
>>>> DIGY
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Phil Haack [mailto:philha@microsoft.com]
>>>> Sent: Monday, November 01, 2010 11:12 PM
>>>> To: lucene-net-user@lucene.apache.org
>>>> 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.
>>>>
>>>> Phil
>>>>
>>>> -----Original Message-----
>>>> From: Digy [mailto:digydigy@gmail.com]
>>>> Sent: Monday, November 01, 2010 2:02 PM
>>>> To: lucene-net-user@lucene.apache.org
>>>> 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 lucene.java does.
>>>> The 1st one needs a "similar" code to "see" the differences easily(I
>>>> haven't found an automated way).
>>>>
>>>>
>>>>
>>>> DIGY
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Phil Haack [mailto:philha@microsoft.com]
>>>> Sent: Monday, November 01, 2010 10:26 PM
>>>> To: lucene-net-user@lucene.apache.org
>>>> 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
>>>> (http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-user/20101
>>>> 1.mbox /raw/%3Ciam8c3$d6g$1@dough.gmane.org%3E/). 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
>>>> (http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-user/20101
>>>> 1.mbox
>>>> /raw/%3C4ccf0425.0f958e0a.1c26.ffffc7d5@mx.google.com%3E):
>>>>
>>>>  keeping the Lucene.Net codebase on par line-by-line with the
>>>>> Java-based project would facilitate easier maintenance of the
>>>>> codebase
>>>>>
>>>> over
>>>>
>>>>> 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.
>>>>
>>>> Phil
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Nic Wise
>>> t.  +44 7788 592806 | @fastchicken | http://www.linkedin.com/in/nicwise
>>> b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise
>>>
>>>
>>


Mime
View raw message