Bug ID: JDK-8080225 FileInput/OutputStream/FileChannel cleanup should be improved

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

Versions (Unresolved/Resolved/Fixed)

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 :	JDK-8187325 - Relax FileInputStream/FileOutputStream requirement to use finalize
Relates :	JDK-8194929 - Unreferenced FileDescriptors not closed
Relates :	JDK-8187631 - Refactor FileDescriptor close implementation
Relates :	JDK-8253568 - Replace and mitigate Object.finalize() uses in JDK libraries
Relates :	JDK-8071507 - (ref) Clear phantom reference as soft and weak references do
Relates :	CODETOOLS-7902045 - Failed to clean up files after test
Relates :	JDK-8189330 - Cleanup FileDescriptor implementation

Sub Tasks

JDK-8193090 :

Release Note: Relax FileInputStream/FileOutputStream Requirement for finalize to Call close - Closed

Description

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.

Comments

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.
21-12-2015
I agree that we should move away from finalizer and use PhantomReference.
29-05-2015
JDK-8071507 would improve a PhantomReference-based solution in those cases where the application failed to explicitly close the stream.
12-05-2015
The issue can be easily worked around by using Files.newInputStream instead.
12-05-2015