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.
