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() {
initFields();
}
private HelloRequest(boolean noInit) { super(true); }
All methods that can modify HelloRequest look like this:
public void setName(java.lang.String value) {
assertNotReadOnly();
hasName = true;
name_ = value;
}
In other words, that example:
myMessage.getSubMessage().setFoo(1);
Would through an exception. just like
Collections.unmodifiableList(java.util.List)<http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collections.html#unmodifiableList(java.util.List)>
does.
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
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
