Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 26 Jun 2012 13:41:44 +0000 (UTC)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <29118488.56377.1340718104181.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <1225060359.55405.1340697647817.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile
 Reader closed, Dictionary Readers left unclosed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401386#comment-13401386 ] 

Uwe Schindler commented on LUCENE-4165:
---------------------------------------

-1, don't close InputStreams. We do this *nowhere* in Lucene.

bq. You said: "This is done everywhere that way." - hm what do you mean with everywhere? Usually at least i do close all my readers which i did create.

I am talking about libraries. Of course the end user code closes the underlying stream. And with the filter-reader contract you are wrong. Reader's and InputStream are a Decorator-Pattern API. The close() call of the wrapper just delegates down, but there is no must to call it.

bq. Whats the problem with calling close on that readers and tell the caller that the stream is consumed and closed?

See my example with ZIPInputStream. If you close the Reader on top, it will close the ZIPInputStream. You have no chance to read the next ZIP-file entry. There are more examples like this.

The design of the Lucene TokenStream API also follows the decorator pattern, the same applies for this one.
                
> HunspellDictionary - AffixFile Reader closed, Dictionary Readers left unclosed
> ------------------------------------------------------------------------------
>
>                 Key: LUCENE-4165
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4165
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: modules/analysis
>    Affects Versions: 3.6
>         Environment: Linux, Java 1.6
>            Reporter: Torsten Krah
>            Priority: Minor
>         Attachments: lucene_36.patch, lucene_trunk.patch
>
>
> The HunspellDictionary takes an InputStream for affix file and a List of Streams for dictionaries.
> Javadoc is not clear about i have to close those stream myself or the Dictionary constructor does this already.
> Looking at the code, at least reader.close() is called when the affix file is read via readAffixFile() method (although closing streams is not done in a finally block - so the constructor may fail to do so).
> The readDictionaryFile() method does miss the call to close the reader in contrast to readAffixFile().
> So the question here is - have i have to close the streams myself after instantiating the dictionary?
> Or is the close call only missing for the dictionary streams?
> Either way, please add the close calls in a safe manner or clarify javadoc so i have to do this myself.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org