-
Bug
-
Resolution: Fixed
-
P4
-
17, 20
-
b08
There are a number of places where the internal implementation
indirectly uses directory streams but neglects to explicitly close them.
It is recommended to always close directory streams to ensure that any
resources held for the open directory are freed.
The usage of directory streams (not closed) is through the following
calls: Files::list, Files::walk, and Files::find. Specifically a number
of unclosed calls are in ModulePatcher, ModuleReferences, ModulePath,
ExplodedImage, and HijrahChronology.
These unclosed streams may not be all that much of a problem in the
happy case (where the stream is exhausted), but can certainly, and have
been noticed, leaking file descriptors in the case where an error occurs
deep in the directory hierarchy. Either way, it is best practice to
ensure that they are always closed.
(note: there are a small number of similar issues in the jlink area, but
they'll be addressed separately)
indirectly uses directory streams but neglects to explicitly close them.
It is recommended to always close directory streams to ensure that any
resources held for the open directory are freed.
The usage of directory streams (not closed) is through the following
calls: Files::list, Files::walk, and Files::find. Specifically a number
of unclosed calls are in ModulePatcher, ModuleReferences, ModulePath,
ExplodedImage, and HijrahChronology.
These unclosed streams may not be all that much of a problem in the
happy case (where the stream is exhausted), but can certainly, and have
been noticed, leaking file descriptors in the case where an error occurs
deep in the directory hierarchy. Either way, it is best practice to
ensure that they are always closed.
(note: there are a small number of similar issues in the jlink area, but
they'll be addressed separately)
- relates to
-
JDK-8290359 Ensure that all directory streams are closed in jdk.link
- Resolved
-
JDK-8290353 ModuleReader::list specification should suggest closing the returned stream
- Resolved