commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <>
Subject [jira] [Commented] (CODEC-225) InputStream not closed
Date Tue, 13 Sep 2016 23:37:20 GMT


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:
>             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

View raw message