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.
