Import immutable ByteString from protobuf #1281

gissuebot opened this Issue Oct 31, 2014 · 6 comments


None yet

4 participants


Original issue created by mmastrac on 2013-02-04 at 04:57 PM

I'd love it if protobuf's immutable ByteString could make it into Guava. This is a useful class, even for users who aren't using protobuf and it seems like a shame to pull in the rest when I'm already importing Guava.


Original comment posted by on 2013-02-04 at 05:07 PM

Agreed...this has been on our radar for quite some time.

Status: Accepted
Labels: Type-Addition, Package-Base

gissuebot commented Nov 1, 2014 edited

Original comment posted by on 2014-01-11 at 02:44 PM

+1 from me, but my motivation is to use both Guava and Protobuf, and have them work better together. e.g. Have ByteString implement ByteSource; return ByteString instead of defensive byte array copies in Guava, etc.

It seems to me that the biggest problem is organizational - i.e. in which project does ByteString live? If in Guava, protobuf would have to depend on it. If in a new "Guava core", Guava would have to maintain that separation. Merging Protobuf-java and Guava would be great, but is probably unacceptable. Having Guava depend on Protobuf (or Protobuf core, containing ByteString) would be 80% good, but wouldn't allow e.g. ByteString to extend ByteSource. etc etc

Any thoughts on the preferred option?


Original comment posted by on 2014-01-12 at 02:41 AM

(No comment entered for this change.)



Original comment posted by andreas.schildbach on 2014-06-01 at 09:25 AM

I think ultimately ByteString should go into the JDK itself.

@cgdecker cgdecker was assigned by gissuebot Nov 1, 2014
@cgdecker cgdecker removed the migrated label Nov 1, 2014
swankjesse commented Jun 19, 2015 edited

Re: Justin's concern, with the existence of protobuf-java-util depending on both Guava and Protobuf, I don't think the two versions would be a big concern. (There can be a util for conversion between ByteString types, and Guava's ByteString can be an abstract class like Protobuf's, allowing wrapper implementations in either direction.)

Re: andreas' comment, agreed too that the JDK should have a concept of an immutable byte view, but I think third-party prototyping and resulting widespread adoption can be a good way to motivate and guide JDK development (see Joda date types, Guava Optionals and functional utils, etc., FluentIterable patterns now incorporated in Stream, etc.).

Out of curiosity, what's the process (if any) for this kind of work?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment