[
https://issues.apache.org/jira/browse/CODEC-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15488816#comment-15488816
]
Gary Gregory commented on CODEC-225:
------------------------------------
DaitchMokotoffSoundex: This a false positive. In general, an input source does
not need to be closed when it is fed into a scanner because closing the scanner
closes the input stream. You will only loose the stream if there is an
exception thrown in parseRules(), which can only happen if the rules file
built-in the jar is broken. Unlikely to happen yet theoretically possible. So
closing both the stream and scanner is redundant.
I think I'll do a pass over the whole code based and use try-with-resources
statements once we move on to Java 7, which will make all of this cleaner.
My plan is to:
- release 1.11 when I get a chance or someone else volunteers
- update to Java 7
- Use try-with-resource blocks.
> InputStream not closed
> ----------------------
>
> Key: CODEC-225
> URL: https://issues.apache.org/jira/browse/CODEC-225
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.10, 1.11
> Reporter: Svetlin Zarev
>
> After running static code analysis on common codecs we discovered that it
> leaks file descriptors. The relevant locations are:
> * DaitchMokotoffSoundex -> the static initializer on line 229
> * Rule -> the static initializer on line 212 and the parseRules() method on
> line 438.
> patch provided via github pull request.
> This issue is relevant for web app deployments on OSes (like windows) that
> lock the files if ther eare open streams to them, and will prevent
> application undeployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
