New Java Protocol Buffers Parser/Code Generator
chi...@gmail.com
First off, I want to thank Google for contributing such a great
project. I wanted to let you guys know that there's now a new Java
based parser/code generator which might interest some of you guys.
The source for it is at:
https://svn.apache.org/repos/asf/activemq/sandbox/activemq-protobuf
My use case for the protobuf is to use it as the next generation of
the wire encoding used in the Apache ActiveMQ message broker. For
those of you know don't know, ActiveMQ is an open source JMS provider.
In this narrow use case, the use of the builder pattern makes it a bit
more cumbersome to work with the messages. This version of the code
generator, uses the standard Java Bean getter/setter pattern. We also
don't need to track unknown fields, message extensions, or use the
reflection bits. So it leaves all those parts un-implemented. So I'm
not sure it can be considered a general purpose implementation of
protocol buffers. It's a lean and mean, 'you better know what your
doing' implementation.
It implements a Java based compiler with an associated maven plugin so
you can easily use it in your maven builds. Ant task would be trivial
to implement, but have not done so just because the build systems I
work with are maven based.
It has a dependency on protobuf-java-2.0.1rc1.jar since it's using
it's CodedInput/OutputStreams but unfortunately there were a few handy
classes that had to be copied from protobuf-java implementation
because of visibility issues. Hopefully, we can work together and get
some of those APIs exposed a bit so that our module can remove the
copies.
Regards,
Hiram
James Bruce
> In this narrow use case, the use of the builder pattern makes it a bit
> more cumbersome to work with the messages. This version of the code
> generator, uses the standard Java Bean getter/setter pattern. We also
> don't need to track unknown fields, message extensions, or use the
> reflection bits. So it leaves all those parts un-implemented.
It would be interesting to see two defined levels of protocol buffer
support. I.e. call what you did Level 1, and if one supports
extensions, unknown fields, etc, call that Level 2. The compliance
tests could be set up to test those things separately. That way, we
could see a lot of semi-related projects that interoperate a little
bit better, without forcing everyone to support everything, since it
doesn't always make sense for some related projects.
I guess I could actually see 3 levels:
1: Compatible with proto wire format
2: Supports compiling from proto files, but without extensions
3: Supports everything
I have no idea what Kenton and friends will think of this, or if its
been debated already, but just putting it out there as a thought.
- Jim