lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: SegmentReader instantiation
Date Thu, 21 May 2009 15:55:44 GMT
On Thu, May 21, 2009 at 10:53 AM, Earwin Burrfoot <> wrote:

>> I agree we should probably remove it, unless there are users relying
>> on this.  Maintaining side-by-side sources is difficult with time.
> As I said in the initial message, this feature introduces no runtime
> behaviour changes, so you can't really 'rely' on it and break if it's
> removed.

Well maybe someone loves the performance improvement... and took
it further by making their own native code extensions.  I'm not
sure how much these gains are.  But people can get quite crazy when
it comes to performance :)

>> Can you send an email to java-user to take a quick survey on whether
>> anyone is somehow needing this?
> Never subscribed there. Too low signal-to-noise ratio. I can, but ..
> is it a must? :)

In fact I find many good ideas for improving Lucene come from our
users, and one can't really understand what's important in Lucene
without being grounded on how it's used.  "Development" and "using" go
hand in hand.

The discussions that take place there spawn still more ideas, and
following those dicussions causes me to think harder about the areas
being discussed, so I learn more myself about Lucene and find
more things to improve and ponder.

Not to mention when there's a sneaky bug, it usually appears on the
users list first.  I jump a those ;)

So, yeah, I think it is a must.  It's likely nobody will respond after
a few days, then we should remove gcj.

I'll go ask if anyone is relying on gcj native code on java-user.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message