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:mitiag...@gmail.com] Gesendet: Dienstag, 2. November 2010 00:56 An: lucene-net-u...@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 <benma...@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:n...@fastchicken.co.nz] >>> Sent: Monday, November 01, 2010 3:32 PM >>> To: lucene-net-u...@lucene.apache.org; an...@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<an...@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:digyd...@gmail.com] >>>> Gesendet: Montag, 1. November 2010 22:32 >>>> An: lucene-net-u...@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:phi...@microsoft.com] >>>> Sent: Monday, November 01, 2010 11:12 PM >>>> To: lucene-net-u...@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:digyd...@gmail.com] >>>> Sent: Monday, November 01, 2010 2:02 PM >>>> To: lucene-net-u...@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:phi...@microsoft.com] >>>> Sent: Monday, November 01, 2010 10:26 PM >>>> To: lucene-net-u...@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$d6...@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.ffffc...@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 >>> >>> >>
