Bug 563580 - Change to try-with-resources results in IOException
Summary: Change to try-with-resources results in IOException
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 4.7   Edit
Hardware: PC Windows 10
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: needinfo
Depends on:
Blocks:
 
Reported: 2020-05-26 05:55 EDT by Michael Wohlfart CLA
Modified: 2020-05-26 13:05 EDT (History)
1 user (show)

See Also:

Attachments
The code location causing the IOException (29.65 KB, image/png)
2020-05-26 05:55 EDT, Michael Wohlfart CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Wohlfart CLA 2020-05-26 05:55:09 EDT 
Created attachment 283017 [details]
The code location causing the IOException

With https://bugs.eclipse.org/bugs/show_bug.cgi?id=500153 the method org.eclipse.core.internal.filebuffers.FileStoreTextFileBuffer.setFileContents(...)  was changed to use try-with-resources. This change now leads to an IOException.

When the output stream is fully read it is closed by the code. Up until the change of Bug 500153 this was completely ok. After the change, the Java runtime will try to close the stream again (auto-closable) which leads to the IOException

Link to code: https://git.eclipse.org/c/platform/eclipse.platform.text.git/tree/org.eclipse.core.filebuffers/src/org/eclipse/core/internal/filebuffers/FileStoreTextFileBuffer.java
Comment 1 Andrey Loskutov CLA 2020-05-26 06:19:12 EDT 
Interesting. Can you provide the stack trace or a sample code producing the IOException? Few default implementations of OutputStream I've checked shouldn't throw on calling close() two times, just wondering which one you have in mind.
Comment 2 Michael Wohlfart CLA 2020-05-26 07:53:17 EDT 
Hmm.. the documentation of Closeable.close() says that invoking it on an already closed stream does not have any effect. This indeed points to a file store implementation that does not honor this contract. Thanks for the hint, looking further into this...