I think I have a solution for the readonly messages.

Message.java now includes the following header:

public abstract class Message {

private boolean readOnly;

protected Message(boolean noInit) {
this.readOnly = true;

public Message() {}
 protected void assertNotReadOnly() {
if (readOnly) {
throw new RuntimeException("Read only message!");

A generated message, HelloRequest, has:

public  final class HelloRequest extends com.google.protobuf.Message {
  public HelloRequest() {
  private HelloRequest(boolean noInit) { super(true); }

All methods that can modify HelloRequest look like this:

  public void setName(java.lang.String value) {
    hasName = true;
    name_ = value;

In other words, that example:


Would through an exception. just like

Do you think this solves the problem?

On Fri, Mar 12, 2010 at 4:16 PM, Igor Gatis <igorga...@gmail.com> wrote:

>   myMessage.getSubMessage().setFoo(1);
>> If they haven't previously called setSubMessage(new SubMessage()) then
>> this code will actually modify the shared default instance of SubMessage
>> which could cause all sorts of bugs around the system.  Have you considered
>> how to avoid this problem?
> Uh, not really. But yeah, that's definitely a problem. Let me think about
> that. I'll get back to you when I have a solution for this problem.
>  So the bottom line is that I had to squeeze the runtime to get it as
>>> small as possible - this is a fully functional protobuf runtime
>>> implementation that occupies 26KB against 173KB of standard Java
>>> implementation.
>> Did you start from the lite implementation or the full one?
>> 26k is pretty impressive.
> Yep, I though LITE_RUNTIME would solve all my problems but generics and
> for-each loops were a problem.
> Flattening the Message class has a few side effects I haven't noticed until
> I implemented equals() and hashCode() methods.
> A bad effect is that now that there is no way to handle fields in a generic
> way, these methods are generated for each message, which makes the size per
> message bigger. For a small set of messages, that's not a problem - and that
> is the most common scenario for J2ME apps.
> A good one is that obfuscators usually removed unused methods. If user
> never uses equals or hashCode, they will be selectively removed. That was
> not possible when AbstractMessage was there.
> BTW, I removed the generic services generation too.

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

Reply via email to