lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karell Ste-Marie" <>
Subject RE: Proposal Stage: Net Idiomatic Api Version
Date Tue, 04 Jan 2011 16:41:18 GMT

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. The main one that comes to mind is the
garbage collector which is different than 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 resources 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 have 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
I think that because people perceive similarities between C# and Java that it 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 engine in a diesel car. While the purposes are the same,
the implementations should 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
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 couldn't help but notice
many of the issues people complain about, are because hasn't implemented lucene

# 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 (instead of Iterators), autoboxing, annotations,

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 .NET users, but better!).

For example, taking a glance, I people making the .NET forks actually doing 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 developers 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 take 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

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