The reason I'm asking all this is that I'm implementing a data
serialization format that has the same usage model as protocol buffers
(i.e. generate language bindings, serialize/deserialize).

For me, the biggest benefit of immutability here is that it prevents
cycles in the object graph.  (Well, I think this is true for Java and
C++.  In Haskell, though, this is not the case).  Without cycles, the
serialization code doesn't have to worry about getting stuck in an
infinite loop (though it's more likely that it'll eventually stack

The downside is the potential inefficiency of making unnecessary
copies of the data structures.  I'm on board with the benefits of
immutability, so I'm usually willing to take the performance hit, but
I wasn't sure if others would be as well.  Have you guys gotten any
requests to add a "generate mutable data structures" mode to protoc?

If I do end up having to support mutable structures, maybe there's
some clever way to efficiently prevent cycles in an object graph as it
is being manipulated.  I really don't want to have to detect cycles in
the serializer (I think cycle detection is what makes Java's built-in
serialization so slow...).

- Kannan

On Thu, Apr 23, 2009 at 15:21, Kenton Varda <> wrote:
> You're specifically talking about the Java implementation.  We quite
> intentionally chose to make message objects completely immutable.  Version 1
> of protocol buffers (never released publicly) used mutable objects, and we
> found it lead to many bugs as people would modify messages that were
> simultaneously being used elsewhere in the app.  To defend against such
> bugs, people had to constantly make "defensive copies" of message objects --
> often unnecessarily, because it was hard to be sure when a copy was
> necessary.
> In C++, we solve this problem using the "const" qualifier, but Java has no
> "const", so we had to go a different route in Java.
> The idea to use immutable objects was actually first suggested to me by Josh
> Bloch (author of Effective Java, and Google employee).  Since I personally
> am a fan of functional programming, I liked the idea a lot and ran with it.
>  Most Java developers inside Google seem to think this was a big
> improvement.
> On Thu, Apr 23, 2009 at 5:03 AM, Kannan Goundan <> wrote:
>> The code generated by protoc seems to go to great lengths to make sure
>> that once a message object is created, it can't be modified.  I'm
>> guessing that this is to avoid cycles in the object graph, so that the
>> serialization routine doesn't have to detect cycles.  Is this
>> correct?  Would a cycle in the object graph put the current serializer
>> into an infinite loop?

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

Reply via email to