Great!  I look forward to seeing it.

On Tue, Mar 16, 2010 at 6:38 AM, Igor Gatis <igorga...@gmail.com> wrote:

> Hi Kenton,
>
> *It seems to me that combining them would only be more work for both of
> us.  I would need you to be available...*
>
> I haven't thought the whole thing through. You're right. It makes more
> sense to keep my implementation in a separated project. Thanks for all the
> advices.
>
> Thanks,
> -Gatis
>
> On Mon, Mar 15, 2010 at 7:54 PM, Kenton Varda <ken...@google.com> wrote:
>
>> I wonder if we should consider making mutable-message mode a feature of
>> the base implementation, rather than j2me-specific.  Some people have
>> requested this, even though I personally think the builder-based design is
>> better.
>>
>> On Fri, Mar 12, 2010 at 7: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.
>>
>>
>> OK, you would know better than me.
>>
>>
>>> 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?
>>>
>>
>> Based on my high-level look, what you have seems good.  But, you don't
>> need my approval for anything.
>>
>> Are you still hoping to add this to the official distribution?  If so, can
>> I ask why you prefer this over maintaining your own project?  It seems to me
>> that combining them would only be more work for both of us.  I would need
>> you to be available to update and test your implementation any time I'm
>> trying to do a release or making Java code generator changes.  Also, you
>> would not be able to release updates to your implementation separately from
>> the protobuf release cycle, which is probably far too slow for a new
>> project.  With the decentralized approach, you do not have to depend on me
>> and I do not have to depend on you.
>>
>>
>>>
>>>
>>> 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