Re: Turning IndexReader.isDeleted implementations to final

Uwe, thanks ! If one uses reflection, then indeed one can load classes dynamically and thus hotspot cannot really be sure when a class won't have any more extensions. If I follow Mike's approach, some Lucene classes are just not mean to be overridden by users because they are internal. In most ca

[jira] Commented: (LUCENE-1410) PFOR implementation

[ https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839509#action_12839509 ] Paul Elschot commented on LUCENE-1410: -- bq. I thought that removing the IntBuffer and

Re: Turning IndexReader.isDeleted implementations to final

> but even non-final methods are inlined by hotspot, if the compiler is sure > that the class was not extended There's absolutely no way a JIT compiler can be sure that the class was not extended (except declaring it final) - because you can create a new classloader and load new class any time you

RE: Turning IndexReader.isDeleted implementations to final

Hi Shai, With Java 5 I only meant, that making the class not fianl would no slowdown potential users of Lucene, as nobody can run Lucene anymore with very old JVM versions like 1.4 or even older. And the Hotspot Compiler of Java 5 is new enough to not require final for inlining. That is the

[jira] Updated: (LUCENE-2283) Possible Memory Leak in StoredFieldsWriter

[ https://issues.apache.org/jira/browse/LUCENE-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-2283: --- Attachment: LUCENE-2283.patch New rev attached with some small improvements: * Ch

Re: Turning IndexReader.isDeleted implementations to final

Reading around I think that Uwe is right. Adding final will only help hotspot, but won't guarantee that not adding it will not result in inlining. If we're sure that these classes really should be final, then let's do it. Otherwise, we might as well not block ourselves, or someone else ... Uwe, I

RE: Turning IndexReader.isDeleted implementations to final

As far as I know, the HotSpot compiler does not really take care of final anymore. In the older java ages that was important, but even non-final methods are inlined by hotspot, if the compiler is sure that the class was not extended and so on. So making a method final just for inlining is no lon

Re: Baby steps towards making Lucene's scoring more flexible...

On Fri, Feb 26, 2010 at 12:50:44PM -0500, Michael McCandless wrote: > * Store additional per-doc stats in the index, eg in a custom > posting list, Inline, as in a payload? Of course that can work, but if the data is common over multiple postings, you pay in space to gain locality. KinoS

Re: Turning IndexReader.isDeleted implementations to final

Sorry, I think the classes? Not sure which others should be... Though it always spooks me out trying to decide if something should really be final... these two are package private so in theory nobody should be extending them, anyway, but if out there someone subclassed them (mixing code into oal.

[jira] Commented: (LUCENE-2291) nighly build should regen all gen'd sources

[ https://issues.apache.org/jira/browse/LUCENE-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839459#action_12839459 ] Uwe Schindler commented on LUCENE-2291: --- For the JFlex parsers we have to wait until

[jira] Created: (LUCENE-2291) nighly build should regen all gen'd sources

nighly build should regen all gen'd sources --- Key: LUCENE-2291 URL: https://issues.apache.org/jira/browse/LUCENE-2291 Project: Lucene - Java Issue Type: Improvement Reporter: Michael McCa

Re: Turning IndexReader.isDeleted implementations to final

What's ok? making the classes final or just the method declaration? If classes, besides ReadOnlySegmentReader, which other impls do you think can be made final (I'm not in front of the code)? On Sun, Feb 28, 2010 at 7:05 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > Seems OK I thin

Re: Turning IndexReader.isDeleted implementations to final

Seems OK I think? Mike On Sun, Feb 28, 2010 at 12:37 AM, Shai Erera wrote: > Hi > > Do you think it's worth to make some of the isDeleted method impls final, > like in ReadOnlySegmentReader and (maybe) DirectoryReader? I'm thinking the > classes that are perceived as final could benefit from tha

[jira] Resolved: (LUCENE-2290) Remove unnecessary String concatenation in IndexWriter

[ https://issues.apache.org/jira/browse/LUCENE-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-2290. Resolution: Fixed Thanks Shai! > Remove unnecessary String concatenation in Index

[jira] Resolved: (LUCENE-2289) Calls to SegmentInfos.message should be wrapped w/ infoStream != null checks

[ https://issues.apache.org/jira/browse/LUCENE-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-2289. Resolution: Fixed Thanks Shai! > Calls to SegmentInfos.message should be wrapped

[jira] Commented: (LUCENE-2289) Calls to SegmentInfos.message should be wrapped w/ infoStream != null checks

[ https://issues.apache.org/jira/browse/LUCENE-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839451#action_12839451 ] Shai Erera commented on LUCENE-2289: Phew .. I was wondering if using words like 'triv

Re: SegmentInfos extends Vector

Ahh ok, the semantics confuse me. I thought of experimental as "we're not yet sure how this thingy will evolve or what it'll turn in to - so feel free to play w/ it but don't count on the API or behavior too much". While 'internal' is more like "we need this public for Lucene internal usage, but we

[jira] Commented: (LUCENE-2289) Calls to SegmentInfos.message should be wrapped w/ infoStream != null checks

[ https://issues.apache.org/jira/browse/LUCENE-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839447#action_12839447 ] Michael McCandless commented on LUCENE-2289: Woops sorry my bad -- I just wasn

Re: SegmentInfos extends Vector

This class is @lucene.experimental, so we are free to break it. +1 to not "extends Vector". I don't think we should change to @lucene.internal since the thinking is apps outside Lucene should be able to introspect and see segment structure in the index. Ie we made this API public so people o

[jira] Commented: (LUCENE-2289) Calls to SegmentInfos.message should be wrapped w/ infoStream != null checks

[ https://issues.apache.org/jira/browse/LUCENE-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839445#action_12839445 ] Shai Erera commented on LUCENE-2289: Are you talking about this: if (exc != null && i

[jira] Assigned: (LUCENE-2290) Remove unnecessary String concatenation in IndexWriter

[ https://issues.apache.org/jira/browse/LUCENE-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-2290: -- Assignee: Michael McCandless > Remove unnecessary String concatenation in Inde

[jira] Commented: (LUCENE-2289) Calls to SegmentInfos.message should be wrapped w/ infoStream != null checks

[ https://issues.apache.org/jira/browse/LUCENE-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839442#action_12839442 ] Michael McCandless commented on LUCENE-2289: Shai, which version did you gener

[jira] Assigned: (LUCENE-2289) Calls to SegmentInfos.message should be wrapped w/ infoStream != null checks

[ https://issues.apache.org/jira/browse/LUCENE-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-2289: -- Assignee: Michael McCandless > Calls to SegmentInfos.message should be wrapped

[jira] Commented: (LUCENE-2289) Calls to SegmentInfos.message should be wrapped w/ infoStream != null checks

[ https://issues.apache.org/jira/browse/LUCENE-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839441#action_12839441 ] Shai Erera commented on LUCENE-2289: Can someone plz help me commit this? The change i

Re: SegmentInfos extends Vector

Ok agreed. I'll do some code investigation and then open an issue. I think that back-compat with this class should not be a (big) problem ... but then - I always think that :). Shai On Sun, Feb 28, 2010 at 4:04 PM, Uwe Schindler wrote: > Hi Shai, > > > > I am only the Generics Police but not t

Re: Adding .classpath.tmpl

So what's the verdict? Does it go into README or BUILD.txt? On Sun, Feb 28, 2010 at 3:26 PM, Erick Erickson wrote: > Tangentially related, but the link on the "how to contribute" page to the > IntelliJ code style file is broken, it reached over into the SOLR Wiki... I > stole the one from SOLR an

[jira] Updated: (LUCENE-2089) explore using automaton for fuzzyquery

[ https://issues.apache.org/jira/browse/LUCENE-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-2089: Attachment: LUCENE-2089.patch attached is an update patch, i left the Lev3Parametric out for simpl

RE: SegmentInfos extends Vector

Hi Shai, I am only the Generics Police but not the Generics Homeland Security and also not the Backwards Homeland Security J I think if we break backwards, lets break it complete and remove the “extends Vector”. And then let’s make the Iterator/Iterable/Collection unmodifiable. That would ge

Re: Adding .classpath.tmpl

Tangentially related, but the link on the "how to contribute" page to the IntelliJ code style file is broken, it reached over into the SOLR Wiki... I stole the one from SOLR and added it as an attachment and the "how to contribute" page now links to it Erick On Sun, Feb 28, 2010 at 5:14 AM, S

Re: SegmentInfos extends Vector

Ok so just that I'm cleared - unmodifiable you mean for iteration only right? And .. do you agree then to refactor the class, or prefer to keep it like that? If you agree, then we need to think if we do that by introducing a new class, or modify the existing one breaking back-compat. A new class i

Re: Lucene Query Parser Syntax document

On Feb 28, 2010, at 8:17 AM, Uwe Schindler wrote: > We may add a symbolic link to the actual version? I would like something like http://lucene.apache.org/java/current to point to the latest release's docs. > But you are right, the syntax is now per-release. Also the system > requirements sin

Re: SegmentInfos extends Vector

IIRC: The early implementation of Vector did not extend AbstractList and thus did not have remove. On Feb 28, 2010, at 8:04 AM, Shai Erera wrote: > Why do you say remove was unsupported before? I don't see it in the class's > impl. It just inherits from Vector and so remove is supported by inhe

RE: Lucene Query Parser Syntax document

We may add a symbolic link to the actual version? But you are right, the syntax is now per-release. Also the system requirements since 3.0 is per-release. The top level site now only contains general infos about lucene no longer any details that may change between releases. - Uwe Schindler

RE: SegmentInfos extends Vector

I meant it was supported by the API, but if you called the modification methods of SegmentInfos you may have corrupted the contents. So implementing List or Collection just throwing UOE is fine, as modifying in Collections can disabled by that exception, the docs state that. But you are righ

Lucene Query Parser Syntax document

Earlier I had linked to http://lucene.apache.org/java/docs/queryparsersyntax.html in my product manual. That no longer works. Searching I found that the document is per release. Not sure when that changed, but having found it at http://lucene.apache.org/java/2_3_2/queryparsersyntax.html I not

Re: SegmentInfos extends Vector

Why do you say remove was unsupported before? I don't see it in the class's impl. It just inherits from Vector and so remove is supported by inheritance. Since the class is public, someone may have called it. Even if we change the class to impl List, period, we'll break back-compat, just because o

RE: SegmentInfos extends Vector

Hi Shai, I forgot to mention: Iterable is always a good idea. E.g. during my 3.0 generification, I made “BooleanQuery implements Iterable” and so on. That makes look the code nice J. Also other classes got this interface in Lucene. Also adding j.io.Closeable everywhere was a good idea. U

RE: SegmentInfos extends Vector

Implementing List to throw UOE everywhere is of course a bad idea, but we can do this for backwards compatibility and simple deprecate such use. I just don’t want to break code that calls get(int) and so on. As remove() or clear() was never supported, it should simply throw UOE. If somebody woul

Re: SegmentInfos extends Vector

I would rather avoid implementing List .. we should implement Iterable for sure, but I'd like to keep the API open either iterating in-order or getting a particular SegmentInfo. Another thing, I haven't seen anywhere that remove is called. In general I don't like to impl an interface just to throw

RE: SegmentInfos extends Vector

I think you should open an issue! I like this refactoring, maybe we can still let it implement List but only deprecated and most methods should throw UOE. Just keep get() and so on. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de

Re: SegmentInfos extends Vector

Yes that's what I've been thinking as well - SegmentInfos should have a segments-related API, not a List related. Whether the infos inside are kept in a Map, List, Collection or array is an implementation detail. In fact, I have a code which uses the API and could really benefit from a Map-like int

RE: SegmentInfos extends Vector

I think this is historically. I have seen this in my big 3.0 generification patches, too. But I did not wanted to change it as Vector has other allocation schema than ArrayList. But maybe we should simply change it, it’s a package-private class, right? But in general subclassing those implem

[jira] Resolved: (LUCENE-2251) Change contrib tests to use the special LuceneTestCase(J4) constant for the current version used a matchVersion parameter

[ https://issues.apache.org/jira/browse/LUCENE-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-2251. --- Resolution: Fixed Fix Version/s: 3.1 Assignee: Uwe Schindler (was: Simon Wil

SegmentInfos extends Vector

Hi What's the reason SegmentInfos extends Vector rather than say ArrayList? Do we need the synchronization around it which Vector provides? Shai

[jira] Commented: (LUCENE-2285) Code cleanup from all sorts of (trivial) warnings

[ https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839411#action_12839411 ] Uwe Schindler commented on LUCENE-2285: --- Of course it would not be needed for Lucene

[jira] Commented: (LUCENE-2285) Code cleanup from all sorts of (trivial) warnings

[ https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839410#action_12839410 ] Shai Erera commented on LUCENE-2285: The @SuppressWarnings is "unused". But I don't wa

[jira] Commented: (LUCENE-2285) Code cleanup from all sorts of (trivial) warnings

[ https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839409#action_12839409 ] Uwe Schindler commented on LUCENE-2285: --- bq. I thought that it's not recommended to

[jira] Updated: (LUCENE-2290) Remove unnecessary String concatenation in IndexWriter

[ https://issues.apache.org/jira/browse/LUCENE-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-2290: --- Attachment: LUCENE--2290.patch Patch w/ the mentioned fixes. > Remove unnecessary String concatenat

[jira] Created: (LUCENE-2290) Remove unnecessary String concatenation in IndexWriter

Remove unnecessary String concatenation in IndexWriter -- Key: LUCENE-2290 URL: https://issues.apache.org/jira/browse/LUCENE-2290 Project: Lucene - Java Issue Type: Improvement Co

[jira] Resolved: (LUCENE-2288) Create EMPTY_ARGS constsant in SnowballProgram instead of allocating new Object[0]

[ https://issues.apache.org/jira/browse/LUCENE-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-2288. - Resolution: Fixed Committed revision 917161. Thanks Shai! > Create EMPTY_ARGS constsant in Sno

[jira] Commented: (LUCENE-2285) Code cleanup from all sorts of (trivial) warnings

[ https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839404#action_12839404 ] Shai Erera commented on LUCENE-2285: Funny how the word 'trivial' appears in the subje

[jira] Commented: (LUCENE-2285) Code cleanup from all sorts of (trivial) warnings

[ https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839403#action_12839403 ] Robert Muir commented on LUCENE-2285: - Shai, its no big deal to me either way, and I a

[jira] Commented: (LUCENE-2285) Code cleanup from all sorts of (trivial) warnings

[ https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839401#action_12839401 ] Shai Erera commented on LUCENE-2285: Thanks Robert. I understand the reasoning behind

[jira] Commented: (LUCENE-2285) Code cleanup from all sorts of (trivial) warnings

[ https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839399#action_12839399 ] Robert Muir commented on LUCENE-2285: - hi Shai, i will give some comment on your examp

Re: Adding .classpath.tmpl

I've read BUILD.txt and it doesn't look like it'll fit there. That files discusses how to build Lucene using Ant and JDK. The word IDE is not mentioned, nor Eclipse. BTW, there is a typo in the file "before returning to this README" - not sure if the word README is intended to be like that, or a l

[jira] Commented: (LUCENE-2285) Code cleanup from all sorts of (trivial) warnings

[ https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839398#action_12839398 ] Shai Erera commented on LUCENE-2285: Uwe, we are indeed deadlocked :). I thought that

RE: Adding .classpath.tmpl

Maybe this change is better in BUILD.txt? I am not sure. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de From: Shai Erera [mailto:ser...@gmail.com] Sent: Sunday, February 28, 2010 10:55 AM To: java-dev@l

[jira] Commented: (LUCENE-2285) Code cleanup from all sorts of (trivial) warnings

[ https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839396#action_12839396 ] Uwe Schindler commented on LUCENE-2285: --- Hi Shai, sorry, in my opinion the discussi

Re: Adding .classpath.tmpl

Index: README.txt === --- README.txt(revision 917047) +++ README.txt(working copy) @@ -28,8 +28,6 @@ part of the core library. Of special note are the JAR files in the analyzers directory which contain various analyzers

[jira] Resolved: (LUCENE-2286) enable DefaultSimilarity.setDiscountOverlaps by default

[ https://issues.apache.org/jira/browse/LUCENE-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-2286. - Resolution: Fixed Committed revision 917148. > enable DefaultSimilarity.setDiscountOverlaps by

RE: Adding .classpath.tmpl

I think we can add this to the README.txt! Do you have a patch? - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de From: Shai Erera [mailto:ser...@gmail.com] Sent: Sunday, February 28, 2010 6:30 AM To: java