> Protocol buffers are objects to serialize things, but it doesn't
> really make sense to use Java serialization to serialize their holder
> objects.
I'd like to pass Java objects from a unserialized protocol buffer
Beans inside a application server. This makes sense to me.

> If you would try to Java serialize the protocol buffer objects, you
> would loose all the functionality you were probably considering using
> Protocol buffers in the first place: version independent, fast and
> platform independent serialization. The object layout might change
> between each protocol buffer library version or you might just change
> the proto definition - all of which will create trouble if you use
> Java serialization; the protocol buffer binary format, however, is
> stable (and compact, and fast, and platform independent ...)
I think you got it wrong: I'm not going to store a protocol-buffer in
java-serialized from, I just need to pass it as an argument between

> So in this case it was actually good that the
> UnmodifiableLazyStringList was not Java serializable - it helped you
> find an improper use.
The deserialized protocol buffers are already implementing teh
interface. Only if you have a repeated String field, it breaks. So I
it as a bug.

> I am not sure what the maintainers think, but I wouldn't add Java
> 'Serializable' to all classes used within the generated objects -
> because then these accidental wrong uses would just go unnoticed.
Sometimes it's just nessesary. And 98% of the buffers are already
Serializable. So somebody has need it before me.



You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to