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

On Thu, Mar 11, 2010 at 6: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.
>
> *- 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.
>
> Does that make sense?
>
> On Thu, Mar 11, 2010 at 4:20 PM, Kenton Varda <ken...@google.com> wrote:
>
>> Can you explain some of the design decisions:
>>
>> - Why did you eliminate the builder pattern?
>>
>> - Why did you choose to implement generic services when this feature is
>> deprecated anyway?
>>
>> 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?
>>
>> =====
>>
>> As far as making this part of the official project, my worry is about
>> maintenance challenges.  It will be much harder for us to make changes to
>> the code generator if we always have to consider J2ME.  For example, when
>> coupled changes to the code generator and runtime library, unless the change
>> is in a part that doesn't apply to J2ME, we would now have to update the
>> J2ME library too.  Not only does this require modifying more files, but it
>> requires setting up J2ME tools for testing -- and our internal build system
>> does not have any support for this AFAIK.
>>
>> So my thought is that the best way to run this is as a branch.  Changes to
>> the official implementation would not affect J2ME until the J2ME branch
>> maintainers choose to update it, and then they could make sure those changes
>> make sense.
>>
>> On Thu, Mar 11, 2010 at 9:16 AM, Igor Gatis <igorga...@gmail.com> wrote:
>>
>>> Here is the code review: http://codereview.appspot.com/445041/show
>>>
>>>
>>> On Thu, Mar 11, 2010 at 2:09 PM, Igor Gatis <igorga...@gmail.com> wrote:
>>>
>>>> It is a stripped copy of the official Java implementation. Here are the
>>>> list of files:
>>>>
>>>> BlockingRpcChannel.java
>>>> BlockingService.java
>>>> ByteString.java
>>>> CodedInputStream.java
>>>> CodedOutputStream.java
>>>> InvalidProtocolBufferException.java
>>>> Message.java
>>>> RpcCallback.java
>>>> RpcChannel.java
>>>> RpcController.java
>>>> ServiceException.java
>>>> WireFormat.java
>>>>
>>>> Limitations:
>>>> 1) Biggest limitation is the lack of support for extensions. I plan to
>>>> fix it soon.
>>>> 2) Also, for J2ME devices, (asynchronous) Services is not a huge
>>>> requirement, so it is not there too (notice there is no Service.java in 
>>>> this
>>>> list).
>>>>
>>>> As for the compiler, there is A LOT of shared code.
>>>>
>>>> I'm sending you a code review.
>>>>
>>>> Thanks,
>>>> -Gatis
>>>>
>>>> On Wed, Mar 10, 2010 at 1:17 AM, Kenton Varda <ken...@google.com>wrote:
>>>>
>>>>> Is your implementation a modification of the official Java
>>>>> implementation?  If so, how much is shared?  Could you send me a diff via
>>>>> codereview.appspot.com?
>>>>>
>>>>> On Tue, Mar 9, 2010 at 5:46 PM, Igor Gatis <igorga...@gmail.com>wrote:
>>>>>
>>>>>> So it is totally out of the scope of this project to add such support?
>>>>>>
>>>>>> The changes I've made seem to match with the current
>>>>>> architecture. I've added extended protoc to accept a new file option
>>>>>> java_platform (where user may specify J2SE(default) or J2ME) which makes 
>>>>>> it
>>>>>> produce J2ME compatible sources.
>>>>>>
>>>>>> On Tue, Mar 9, 2010 at 10:29 PM, Kenton Varda <ken...@google.com>wrote:
>>>>>>
>>>>>>> There are three J2ME implementations on the third-party list:
>>>>>>>   http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
>>>>>>>
>>>>>>> I'd be happy to list yours as well if you'd like.
>>>>>>>
>>>>>>> On Tue, Mar 9, 2010 at 5:17 PM, Igor Gatis <igorga...@gmail.com>wrote:
>>>>>>>
>>>>>>>> Hi protobuf team,
>>>>>>>>
>>>>>>>> Have you guys considered supporting J2ME?
>>>>>>>>
>>>>>>>> I've extended protoc to generate J2ME compatible code and built its
>>>>>>>> supporting J2ME runtime library. I was wondering if you guys would 
>>>>>>>> consider
>>>>>>>> reviewing my changes.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Gatis
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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<protobuf%2bunsubscr...@googlegroups.com>
>>>>>>>> .
>>>>>>>> For more options, visit this group at
>>>>>>>> http://groups.google.com/group/protobuf?hl=en.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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