Which tool were you using for this? Sharper? or the other one?

(just curious)
On Tue, Nov 2, 2010 at 13:02, Andreas Mummenhoff wrote:
what I found out from the converted source is interesting:

a) generics are used, for example in class Document.cs:

///   <summary> Returns a List of all the fields in a document.
///   * <p>Note that fields which are <i>not</i> <seealso
cref="Fieldable#isStored() stored"/> are
///   * <i>not</i> available in documents retrieved from the
///   * index, e.g. <seealso cref="Searcher#doc(int)"/> or {@link
///   * IndexReader#document(int)}. </summary>
public IList<Fieldable> getFields()
return fields;

in class CharArraySet.cs:

/// <summary> returns an iterator of new allocated Strings  </summary>
public virtual IEnumerator<string> stringIterator()
return new CharArraySetIterator();

b) there exists an option to convert getXXX, setXXX to properties, you have
to fill a list with names which should be converted, I tried "Boost", the
result in Document.cs:

///   <summary> Sets a boost factor for hits on any field of this document.
This value
///   * will be multiplied into the score of all hits on this document.
///   *
///   * <p>The default value is 1.0.
///   *
///   * <p>Values are multiplied into the value of <seealso
cref="Fieldable#getBoost()"/> of
///   * each field in this document.  Thus, this method in effect sets a
///   * boost for the fields of this document.
///   * </summary>
///   * <seealso cref= Fieldable#setBoost(float) </seealso>
public float Boost
this.boost = value;
return boost;

this means, some kind of .Netifying is already performed WITHOUT
additionally work.

-----Ursprüngliche Nachricht-----
Von: Simone Chiaretta
Gesendet: Dienstag, 2. November 2010 12:45
An: lucene-net-user; anmum
Betreff: Re: Lucene.NET Community Status

Another possibility to have more .NET is to keep Lucene.Net the way it is
now: line-by-line port and ugly java-ish API, and then write a small wrapper
library that maps the java-like API to something more .NET.

For example, the various SetSize(size) and GetSize() could be mapped to a
Size property, and similar things.
It would help maintain the easiness of maintainability of the line-by-line
port, and will make the API more .NET-like.

On Tue, Nov 2, 2010 at 12:21 PM, Andreas Mummenhoff wrote:

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
TODO TASK       Anonymous inner classes are not converted to .NET:
TODO TASK       C# does not allow fall-through from a non-empty 'case':
TODO TASK       Enums cannot contain methods in .NET:
TODO TASK       Interfaces cannot contain fields in .NET:
TODO TASK       Interfaces cannot contain types in .NET:
TODO TASK       Java wildcard generics are not converted to .NET:
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#:
TODO TASK       The following line could not be converted:
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:
WARNING 'final' parameters are not allowed in .NET:
WARNING Method 'throws' clauses are not available in .NET:
WARNING The original Java variable was marked 'final':
WARNING Unlike Java's ListIterator, enumerators in .NET do not allow
altering the collection:        2.

-----Ursprüngliche Nachricht-----
Von: Michael Mitiaguin
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 (
mentioning to the group - to avoid the same work ;  however,  it is
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,
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 (
stumbling block ) how to keep up with Java Lucene.
On Tue, Nov 2, 2010 at 10:12 AM, Ben Martz wrote:

I'm glad that my previous email appears to not have gone through since
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:
(there's a link to source code repository at the bottom of the page)

On 01/11/2010 22:37, Phil Haack wrote:

Anyone know which translator does the best job? Perhaps we should
which is our preferred tool for translation (maybe with a #2 and #3
and if cost is an issue, we can tackle that together. It seems to me
helping out with the cost is something that a foundation ought to help
:) But if the Apache foundation doesn't pony up the money for the
maybe we can ask around. I'd be happy to see if I know any companies
can help with sponsorship to purchase a license for such software.


-----Original Message-----
From: Nic Wise
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.


It was used here (recently - over the weekend I think) to port JGit

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
3 month trip away, with limited internet for a lot of it....  So I'll
to see where things are when I get back...

On Mon, Nov 1, 2010 at 22:26, Andreas Mummenhoff<anmum@online.de>
Hi Digy,

maybe you know db4o, which is available for Java and .Net. As far as
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,
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
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

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
few hundred $ will not be the problem.


-----Ursprüngliche Nachricht-----
Von: Digy
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

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


-----Original Message-----
From: Phil Haack
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
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
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
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
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).


-----Original Message-----
From: Phil Haack
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
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
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
approach was

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
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
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
Perhaps by making the library more ".NET Friendly", the extra cost to
do the port is more than outweighed by the extra involvement of
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.


Nic Wise
t.  +44 7788 592806 | @fastchicken |

Simone Chiaretta
Microsoft MVP ASP.NET - ASPInsider
Blog: http://codeclimber.net.nz
RSS: http://feeds2.feedburner.com/codeclimber
twitter: @simonech

Any sufficiently advanced technology is indistinguishable from magic
"Life is short, play hard"

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

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2018 Grokbase