If this approach is taken, I’d like to suggest using a ‘final’ var instead of
‘null init/null check’, for example:
public AudioInputStream getAudioInputStream(File file)
throws UnsupportedAudioFileException, IOException {
final FileInputStream fis = new FileInputStream(file);
try
On 08.01.2015 1:13, Phil Race wrote:
Its not clear to me if the bug description is implying an exception
was thrown
UnsupportedAudioFileException is thrown if the URL/File does not point
to valid audio file data recognized by the specific reader, so
AudioSystem will try to move to the next read
Its not clear to me if the bug description is implying an exception was
thrown or
if there is an additional reason the file cannot be closed.
Still, something like what you suggest seems to be needed.
The owner of this bug is out until next week so I'll let him comment further
after his return.
Hello all,
I wanted to post this as a comment on
https://bugs.openjdk.java.net/browse/JDK-8013586, but apparently getting
comment access to that system is a bit of a hurdle. Anyway. What follows
is, I believe, a fix for the aforementioned bug:
There is a file handle leak in some of the subclass
