JDK-8080225 : FileInput/OutputStream/FileChannel cleanup should be improved
  • Type: Enhancement
  • Component: core-libs
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-05-12
  • Updated: 2018-01-11
  • Resolved: 2017-12-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10 b36Fixed
Related Reports
CSR :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8193090 :  
FileInputStream relies on finalization to perform final closes if the FIS is not already closed.
This results in extra work for GC that occurs in a burst.  The cleanup of FileInputStreams
should happen sooner and not contribute to overhead in GC.
With PhantomReferences a lightweight cleanup mechanism or other suitable mechanism could be implemented.

The unresolvable compatibility issue is the requirement in FileInputStream and FileOutputStream finalizer methodss to call close. The proposed reference based cleaners can not implement anything calling close() because it would require holding a reference to the FIS/FOS which would prevent the stream from becoming phantom referenced. Since it is unknown/unknowable how many FIS/FOS subclasses might rely on overriding close or finalize the compatibility issue is severe. Only a long term (multiple release) restriction to deprecate or invalidate overriding would have possibility of eventually eliminating the compatibility problem.

I agree that we should move away from finalizer and use PhantomReference.

JDK-8071507 would improve a PhantomReference-based solution in those cases where the application failed to explicitly close the stream.

The issue can be easily worked around by using Files.newInputStream instead.