On Thu, Mar 11, 2010 at 1:52 PM, Igor Gatis <igorga...@gmail.com> wrote:

> *- Why did you eliminate the builder pattern?*
>
> To save jar space. J2ME environment is pretty restricted. Many devices have
> a few kilo bytes size limit (e.g 128K, 256K). An empty class adds about 200
> bytes to jar file. The long time I worked with J2ME convinced me the less
> classes the better. I tried to keep it as simple as possible without hurting
> the OO design.
>

Hmm, I'm surprised that you could even get anything resembling the Java
protobuf implementation to fit in such a small space.  You could possibly
get it even smaller by using POJOs (avoid getters and setters).

One thing that worries me about removing the builder pattern is that it
changes the whole usage model in a way that could affect other design
decisions.  For example, if you have a message-typed field which has not
been set yet, the getter for that field should return the message type's
default instance.  This was fine when default instances were immutable, but
now that they are mutable, you might have bugs where someone writes:

  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?


> *- Why did you choose to implement generic services when this feature is
> deprecated anyway?*
>
> That was overseen. I need to fix that then.
>
> *Your diff shows the runtime classes as if they were completely new.
>  Could you re-arrange the files so that it actually compares your versions
> of these classes against the official ones?*
>
> The some official java sources are not Java 1.3 compatible (for instance,
> they use generics and for-each loops). I've also flattened some of the
> classes hierarchy (e.g. Message vs AbstractMessage + GeneratedMessage +
> MessageLite, etc) to save jar space. I've also removed dependency to
> Descriptors so I had to change  BlockingRpcChannel and RpcChannel to receive
> the method as a String rather than a descriptor. So that being said, the new
> set of files are tailored to J2ME environment and its limitations.
>
> 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.

On Thu, Mar 11, 2010 at 4:26 PM, Igor Gatis <igorga...@gmail.com> wrote:

> What exactly is deprecated in the services API? Is it only the Service and
> BlockingService interfaces?


We are now encouraging RPC implementations to provide their own code
generator plugins rather than work with the "generic" services.  This way
implementations can tailor the generated code to their purposes.

Note that services were never part of the "lite" implementation.

-- 
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