On Wed, Apr 29, 2009 at 1:14 PM, burtonator <burtona...@gmail.com> wrote:
> > I have a few thoughts after looking at the generated Java source. > > No particular order... > > - why does the class have to be final? I can see one wanting to have > business logic (or data type manipulation logic) that protobufs don't > provide in a class that extends the protobuf itself. Several reasons: 1) In protocol buffers v1 (not released publicly), classes were not final, and in C++ classes cannot be declared final. What we've found is that when people subclass generated types, it only creates problems. Googling "fragile base class" brings up several pages that describe exactly the kind of problems we had. 2) Implementation inheritance is bad design. Even some of the creators of Java are now on the record saying that they wish they never allowed this. Again, lots of sources on the internet discussing this. 3) When calling code that you don't trust (e.g. a dynamically-loaded applet), it's useful to be able to know that if the code gives you an object of a protocol message type, it's impossible for the object to have been extended with malicious behavior. Otherwise, you would be forced to make a defensive copy in order to sanitize the object. In other words, allowing subclassing could lead to security vulnerabilities. Admittedly, though, this is a pretty unusual use case for protocol buffers. > - why use static inner classes to build the API? Perhaps the compiler > can't write new .java files? In .protos with lots of classes this can > get pretty ugly pretty fast. Are there technical reasons do to this? Many people feel that it is cleaner for a single .proto file to produce a single .java file. However, if you want to produce a separate file for each class, you can use: option java_multiple_files = true; Note that the outer class will still be generated as well, since it needs to hold the file-scope stuff (like the file descriptor and top-level extensions). However, we may try to work around this in the future, such that if you don't explicitly set java_outer_classname, no outer class is generated at all. > I was thinking that one solution could be to have two different > generation styles. One that uses the more common POJO format and > another that uses this current static inner class format. You are welcome to write an alternate code generator, but I don't think we'll be adding POJO output to the official implementation. The version 1 implementation was more POJO-like, with mutable objects instead of separate builders, and our experience with that was that it lead to a lot of bugs with people modifying objects they weren't supposed to modify, and having to make lots of defensive copies to avoid those bugs. > My thinking on the current format is that Java developers are going to > look at this and be all WTF and then walk away....... maybe it's just > me ;) That's not the reaction I've seen from most Java devs. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@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 -~----------~----~----~----~------~----~------~--~---
