lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Mateja <>
Subject Re: [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool
Date Fri, 07 Jan 2011 17:53:19 GMT
Nice work Alex!

Not that this represents a solution, but I did load up the core source from
your conversion into a VS2010 project, then ran Resharper's code cleanup on

This process took care of all the unused 'using Java.*' references, cleanup
up formatting, etc.  However, I'm still seeing a good many things that need

1) ICloseable -> IDisposable, including refactoring of the implementation
from Close() to Dispose() (and also considering any additional refactoring
of the Disposable pattern.)
2) IFieldCache is marked as an interface, but has tons of static fields,
subclasses and interfaces.  This may be ok in Java, but not in C#.  Not sure
what the best course of action here might be... perhaps create an abstract
base class called FieldCache or FieldCacheBase to house this stuff, and pull
out the nested classes / interfaces into their own files.
3) Use of a generic WeakReference<>, which doesn't exist in generic form in
the .Net Framework.  This is something which could either be refactored or
implemented as generic.
4) ICloneable interface not implemented (see IndexInput.cs)
5) Unsigned bitwise shift assignment operator doesn't exist in C#.  See
IndexOutput.cs, WriteVInt() method.  The line i >>>= 7; in java flags an
error in C#.  I'm not entirely sure in this case, but I believe this can
safely be converted to: i >>= 7; in this case, especially given the comment
that negative numbers are not supported.
6) Use of Java DecimalFormat class.  An appropriate .Net replacement should
be easily substituted with some refactoring of the code.
7) Use of Runtime.IdentityHashCode().  Not sure how necessary this is.
8) Java specific value type parsing calls should be refactored to .Net (e.g.
double.ParseDouble() => double.Parse())
9) Use of the java ReadResolve() object serialization pattern needs to be
analyzed / refactored (see FieldCache.DefaultByteParser (or in the
translated version, IFieldCache._IByteParser)).
10) Use of Sharpen references.
11) Use of Java's NumberFormatException... should be refactored to use an
appropriate standard exception type (perhaps FormatException, though I'm not
sure this is appropriate) or create an internal Exception class for this

There's plenty more build issues... I need to put this down for the rest of
the day, so I thought I'd at least get this out to the list.

Peter Mateja

On Fri, Jan 7, 2011 at 9:34 AM, Neal Granroth (JIRA) <>wrote:

>    [
> Neal Granroth commented on LUCENENET-380:
> -----------------------------------------
> Thanks Alex,
> What would be the plan for handling the Sharpen artifacts that prevent the
> converted code from being built by the .NET SDK compiler?
> Do you envision a post-conversion script to strip out statements like:
> using Java.Lang
> using Java.IO
> and replace Sharpen-specific classes with standard .NET classes:
> Sharpen.Collections.*
> Sharpen.Runtime.*
> > Evaluate Sharpen as a port tool
> > -------------------------------
> >
> >                 Key: LUCENENET-380
> >                 URL:
> >             Project: Lucene.Net
> >          Issue Type: Task
> >            Reporter: George Aroush
> >         Attachments:,
> >
> >
> > This task is to evaluate Sharpen as a port tool for Lucene.Net.
> > The files to be evaluated are attached.  We need to run those files
> (which are off Java Lucene 2.9.2) against Sharpen and compare the result
> against JLCA result.
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message