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