lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Paldino [.NET/C# MVP]" <>
Subject RE: Proposal Stage: Net Idiomatic Api Version
Date Tue, 04 Jan 2011 18:04:57 GMT

	I was just about to comment on this (with the same links mind you).
The ^proper^ implementation of IDisposable where Closable is used is the
best approach.

	To Robert, just because IDisposable is implemented doesn't mean that
it ^must^ be used in a using statement (which is not the same as finally,
but has some similarities).  I've implemented wrappers around anything that
exposes a Close method in an older version of Lucene.NET so that I can use
IDisposable on them, including IndexReader.

	However, I choose not to use IndexReader in a using statement, I
open mine and store a reference to it.  The great thing about implementing
IDisposable properly is that one would have a finalizer as well which would
call Dispose (rather, the protected overload) in the event that the app
domain is torn down or the object reference is let go without Dispose being
called on it (I actually think the latter case is a design flaw on the part
of the consumer of the object, and would rather see an exception thrown in
this case, but you can't control other people's implementations, and
everyone follows the current guidelines).

	From the .NET perspective, the IndexReader/Writer will most
definitely have to implement IDisposable, as it will contain references to
other IDisposable implementations (Directory) which should also be disposed
of when Dispose is called.

	It should be noted that there is a difference between an
implementation of the IDisposable interface and a Close method.  In the .NET
world, it's a given (though not codified through an interface or guideline)
that if you have a Close method, the following applies (again, not all the
time, but you can see it in practice):

- There is an Open method
- Dispose calls Close

	This way, you can use the resource in a using statement and it will
close the resource properly.  However, if you wanted, you could close the
resource and then reopen it with the Close/Open methods.  The most prominent
case of this is the DbConnection class
x) which serves as the base class for all database connections in ADO.NET.

	To Karell, sorry, but I'm going to have to snipe.  In regards to the
"quirks" you mention with the CLR GC, and having to free resources by
calling IDisposable in the face of that (and then saying "in a world where
GC exist, who would have thought"), the same exact situation exists with the

	The CLR and the JVM GC are meant to deal with ^managed^ resources
and memory.  This means that when you allocate space from the heap, etc, it
can keep track of it.  However, when dealing with managed wrappers to
unmanaged resources, one needs to have a definitive way of releasing those
resources; in the unmanaged world, it was assumed those resources were
disposed of as soon as their use was complete (typically through RIIA), the
managed world does not make any guarantees, hence the need for IDisposable
in .NET and Closable in Java.

	The point is, the situation that you say is a "quirk" with .NET is
directly related to the fact that .NET has to interact with code that is not
managed, and Java shares the exact situation, with the same caveats and

		- Nicholas Paldino [.NET/C# MVP]

-----Original Message-----
From: Peter Mateja [] 
Sent: Tuesday, January 04, 2011 12:15 PM
Subject: Re: Proposal Stage: Net Idiomatic Api Version

Robert... good points all.  I especially agree that basing initial idiomatic
work on 3.0+ makes sense (indeed, I believe this is what Lucere.Net had
agreed to do.)

Use of IDisposable can certainly lead to worst practices concerning
IndexReader / IndexWriter objects.  However, the IDisposable pattern
(if implemented correctly... see, and Framework Design
Patterns book mentioned earlier), really is the best way (in .Net) to ensure
proper handling of both unmanaged resources, and stateful managed resources.

I think a good combination of documentation and examples could do much to
discourage worst practices.  In some cases, the sample 'using' code you
refer to might be appropriate... though in most the lifetime of an
IndexWriter object might be controlled at a higher context (AppDomain, etc.)
 Let's ensure that Lucene.Net users know the how and why for each approach.

Peter Mateja

On Tue, Jan 4, 2011 at 10:41 AM, Karell Ste-Marie

> Robert,
> Thanks for stepping in,
> I personally found some of your suggestions quite interesting and
> completely agree that Lucene 3.0 may help quite a bit.
> Not that I want to place myself in the bullseye of any .NET snipers out
> there but the .NET framework (like any others) has its share of quirks.
> main one that comes to mind is the garbage collector which is different
> in Java. The same can be said for some of the behavior of the CLR when
> compared to the JVM. I recall implementing IDisposable myself in a few
> objects and while you may consider that the GC should run and free
> by calling Dispose on an IDisposable object this is actually a technique
> that is discouraged because there is no telling when the GC will actually
> free up a resource - you may laugh at this but when it comes to bad
> practices I've seen newbie .NET programmers easily create memory leaks by
> not manually closing resources (in a world where a GC exist, who would
> thought...)
> In the end, the languages are different - the whole conversation about
> Generics could also be a very interesting topic, we could also talk about
> WCF quite a bit. This is where personally the line-to-line port of Lucene
> from Java to .NET is IMHO a difficult endeavor. One would not try to do a
> line-to-line port from Java to Perl. The languages are too different. But
> think that because people perceive similarities between C# and Java that
> is assumed that it's a good idea. However - and this is where opinions
> diverge - this would be in my point of view like trying to fit a gas
> in a diesel car. While the purposes are the same, the implementations
> be different (at least in some areas) because the technologies are
> different.
> My Canadian 2 cents - subject to the exchange rate
> Karell Ste-Marie
> C.I.O. - BrainBank Inc
> -----Original Message-----
> From: Robert Muir []
> Sent: Tuesday, January 04, 2011 11:27 AM
> To:
> Subject: Re: Proposal Stage: Net Idiomatic Api Version
> On Tue, Jan 4, 2011 at 10:49 AM, Peter Mateja <>
> wrote:
> >> I made a request of the community in the Lucere project mailing list
> >> to respond with ideas about what an ideal .NET API would look like,
> >> and how it would function. Specifically, I was hoping to get
> >> pseudo-code examples of how end users would like to use Lucene. Even
> >> something as simple as:
> >>
> >> using(var luceneIndex = new LuceneIndex.Open("C:\foo\bar")) {
> >>  var hitDocs = from doc in luceneIndex where
> >> doc.Field["content"].Match("foo") select doc; }
> Hi guys, I know almost nothing of .NET (lucene java developer here), but I
> was hoping I could provide some suggestions here to help out.
> In glancing at some of the issues surrounding a more ".NET" api, i
> help but notice many of the issues people complain about, are because
> hasn't implemented lucene 3.0
> # lucene 3.0.x is the same feature-wise as lucene 2.9.x, no new features.
> # lucene 3.0.x is Java 5, which is almost a different programming language
> than Java 4 (2.9.x). This means enums, generics, Closeable, foreach
> of Iterators), autoboxing, annotations, etc.
> A lot of the issues people have raised seem to be due to the fact that
> lucene 2.9.x is in an ancient java version... I think if you ported 3.0,
> things would look a lot more idiomatic (although surely not perfect for
> users, but better!).
> For example, taking a glance, I people making the .NET forks actually
> things like taking the 2.9.x code and converting to use enums,
> which is really a duplication of effort since we did this in java over a
> year ago!:
> So, I'm suggesting that one thing you could consider is to start focusing
> on lucene 3.0.x, to also produce a more idiomatic api automatically, and
> possibly this would be a good enough improvement to bring in some
> from those forks.
> Separately, I'm trying to understand the syntax you provided about
> IDisposable/using. Obviously, as part of your porting process you could
> anything marked Closeable [we marked anything wtih a
> .close() as Closeable in Lucene 3.0], and mark it IDisposable, but is this
> really the best approach?
> For example, the syntax you provided seems like it would encourage closing
> the IndexReader and opening a new one for each search request... yet this
> about the biggest no-no you can do with a lucene index... opening a new
> IndexReader is very heavy and you should re-use it across queries and not
> open/close them often... so in this case, a more idiomatic API could
> actually be bad, if it encourages worst practices...

View raw message