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 a...@antonov.ws 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 proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%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.
