I've uploaded my latest version.

http://codereview.appspot.com/445041/show

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

> My experience with J2ME says performance is not the most important feature
> for the majority of the applications. Trust me when I say JAR size is the
> one people care the most.
>
> Besides, the extra cost is a method call + condition check, that's fairly
> cheap. Depending on the compiler and/or obfuscator, that condition could
> even be inlined saving the extra method call.
>
> I still need to go over all files to check code compliance with the style
> guide and write tests. But besides that, do you think I still need to change
> the design?
>
>
> On Fri, Mar 12, 2010 at 9:10 PM, Kenton Varda <ken...@google.com> wrote:
>
>> This may solve the problem but adding code to every setter may have a
>> significant cost.  It's harder to inline the setter this way.  But it's hard
>> to say exactly what the cost will be without some sort of benchmarks.
>>
>>
>> On Fri, Mar 12, 2010 at 12:12 PM, Igor Gatis <igorga...@gmail.com> wrote:
>>
>>> 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.

Reply via email to