ByteSink based on ByteArrayInputStream

[GoogleCodeExporter]

Hello guava team,

I have used the new Bytesources and -sinks for great success in an IO-heavy 
Java6 project. They were used instead of files whenever simple IO-Resources 
were needed. What I felt is still missing in guava 15 are array-based Byte- and 
CharSinks which can be converted into Byte/CharSources afterwards.

As an example of what I mean you'll find two rather naive implementations  
based on an internal ByteArrayOutputStream and CharArrayWriter in the 
attachement which I created for my project. The interface is rather rich since 
I used them mostly for testing.

Is such a feature planned for a future guava release?

Original issue reported on code.google.com by Eric6i...@googlemail.com on 17 Dec 2013 at 1:52

Attachments:

• ByteArraySink.java
• CharArraySink.java

[GoogleCodeExporter]

This is something that I like the idea of and have done some thinking about, 
but there are no immediate plans.

There are quite a few different ways the API could be designed and I haven't 
come to any conclusion on what's best. It makes sense to me for these to be 
general in-memory byte/char storage types (with methods on them for appending 
bytes/chars directly when you want to), but should they extend Byte/CharSink? 
Or should they extend Byte/CharSource? Or neither, and just have methods for 
viewing them as one or the other. Or neither, and they should be in base since 
they're more generally just byte and char related, and create methods in io 
that wrap them as a Source/Sink? For example, StringBuilder is similar to what 
we might want for an actual storage type, other than not having methods for 
viewing it as an I/O stream/source/sink.

Original comment by cgdecker@google.com on 17 Dec 2013 at 6:57

• Added labels: Package-IO, Type-Addition

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yep there's a lot of design questions to answer, I guess.

What I think is crucial is the possibility to use the written data directly 
with a ByteSource/CharSource-Wrapper, even if this could cause undefined 
results on later write-operations. This shouldn't really be a problem at all as 
long as you do not let the mutable Buffer but only the Source return from 
method scope. Always defensively copying the array can be much more risky in 
the face of OOME.

However, this would rule out the possibility to use wrappers around 
StringBuilder and the like, since you need the array under direct control.

Original comment by Eric6i...@googlemail.com on 17 Dec 2013 at 8:12

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:10

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:17

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit