On Thu, May 21, 2009 at 10:53 AM, Earwin Burrfoot <ear...@gmail.com> 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. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
