lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Mummenhoff" <an...@online.de>
Subject AW: Lucene.NET Community Status
Date Tue, 02 Nov 2010 13:02:31 GMT
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
default
///   * boost for the fields of this document.
///   * </summary>
///   * <seealso cref= Fieldable#setBoost(float) </seealso>
///   
                  public float Boost
                  {
                                 set
                                 {
                                               this.boost = value;
                                 }
                                 get
                                 {
                                               return boost;
                                 }
                  }




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







-----Ursprüngliche Nachricht-----
Von: Simone Chiaretta [mailto:simone.chiaretta@gmail.com] 
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.

Simone

On Tue, Nov 2, 2010 at 12:21 PM, Andreas Mummenhoff <anmum@online.de> 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
> 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
> >>>
> >>>
> >>
>
>


-- 
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"


Mime
View raw message