Google's build system requires all dependencies to be explicitly declared and enforces this. This is needed in order for the system to scale to very large code trees: when we want to compile a particular program or test, we want to compile only the things it depends on, not the whole tree. The build system further assumes that protoc-generated Java code depends only on libprotobuf.jar, so that's the only thing it puts in the classpath when compiling that code. To change that, we'd have to add new features to the build definition language to allow you to declare a Java library as a dependency of a Proto library. This is something I have tried to avoid because an earlier version of protocol buffers allowed it (even though it was never actually needed), and the result was that people would declare dependencies that were not actually necessary, thus forcing everyone who used their proto to depend on code they didn't need.
But this is just one example of the kind of quirks I'm talking about. Another one: Imagine someone writes some code that can take .proto files and compile them at runtime by invoking protoc and the java compiler in the background, then tries to load the class files. Currently, you could theoretically do this. With your feature, though, you can't anymore -- this code would have to carefully go through and make sure to delete all instances of the java_implement_interface option to make it work. These are minor issues in isolation, but I worry that they are just a couple examples of a large class of problems that would be caused by Java generated code depending on arbitrary app code. On Mon, Nov 23, 2009 at 6:28 PM, aantono <[email protected]> wrote: > Kenton, > > You certainly can do that as well. However, as you pointed out, > that's a lot of extra code that one would have to hand-write and > maintain. This is why I thought it might be a good idea to solicit > more opinions from the community to help get a better sense of what's > the lesser of two evils. I see your point of introducing the implicit > dependency between protoc and application code, but it is implicit, > and won't prevent one from generating the proto java objects, just > won't compile afterwards if the declared interface is not present. > But the same holds true for having the wrappers, if they are not > present in the classpath at compile time, it won't work. This > dependency is isolated to a particular VM, but having an interface(s) > allows for easier use of objects representing "concepts" without > having to resort to reflection. It seems to me that at the end of the > day its all about the business needs and convenience, so the less code > one has to write and maintain, the better. > > Also, can you elaborate (if possible) on why would this not work with > Google's internal build system > > -- > > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<protobuf%[email protected]> > . > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
