BaseEncoding.encodingStream().close() is non-idempotent
See original GitHub issueCloseable.close
says:
If the stream is already closed then invoking this method has no effect.
Code:
StringWriter w = new StringWriter();
OutputStream out = BaseEncoding.base64().encodingStream(w);
out.write(0);
out.close();
System.out.println(w);
out.close();
System.out.println(w);
Output:
AA==
AA==A===
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
[gs-commits] ghostpdl annotated tag, ghostscript-9.20, created ...
Bug 692026: Replace vsprintf() with vsnprintf() Fix Cygwin build. ... Bug 693279: font: default base encoding Bug 692750: have gdevwpr2 ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Being idempotent is useful; it’s very easy to double-close a stream due to ARM blocks and wrapping streams that close their underlying streams.
Synchronization is probably unnecessary. Java I/O streams are generally synchronized, but I’ve never seen anyone use multiple threads to concurrently read or write a shared stream.
It looks like the problem is just that
close
doesn’t adjustbitBufferLength
. I don’t think thread-safety is required.