By "wrapping C++ compiled protobufs"  I'm assuming that the protocol
buffers in transit are serialized as protobufs... so the C++ is a non-
issue (unless you mean some bizarre struct-based comms are going on...
in which case good luck ;-)

If you're in a web server environment you're probably better off
generating the java code as it will perform better and be easier to
interact with than dynamic protobufs code.  If you have program size
constraints then dynamic is certainly the best way to keep code size
down as long as you're willing to deal with the increased complexity
(for you).

I use dynamic protobufs as I'm often working in an environment where I
don't always know what protocol buffers I will be using until run time
- at which point the FileDescriptorSet can be used to work with any
protobufs.  For instance, this is useful when developing tooling for
Domain Specific Languages in the Eclipse IDE that are based on
protocol buffers.  As it is somewhat difficult and clumsy to do class
loading for project class files, the FileDescriptorSets are an
excellent way to get generic access to any proto file being used.

If you do get stuck working with protobufs the purely dynamic way -
feel free to post here anytime.  The dynamic usage is poorly
documented and there are various 'land mines' I've run into through my
usage - I would be happy to save you the same trouble.

On Oct 6, 9:51 am, Dale Durham <> wrote:
> Benjamin,
> Thanks for the detailed and very helpful responses! First and
> foremost, believe me when I say that the decision to tinker with the
> more advanced protobuf features was somewhat forced on me, not a
> choice that I made. I have to decode messages sent over the wire as
> AMQP messages that are wrapping C++ compiled protobufs from a legacy
> system.
> I need to make the protobuf message details visible off-platform via a
> browser, thus the choice for Java in favor of just using C++. Once I
> receive the AMQP messages off-platform, I have no need or concern for
> serialization from that point on, only display. I am pretty sure that
> one I have the file descriptors, the rest will be fairly easy. I could
> just generate the java source as you indicate below, but I thought
> that may be a bit more expensive than just creating the file
> descriptors, especially given that we have a huge amount of messages.
> Thanks again for the rapid and detailed response! Hopefully, I'll get
> some time today to muddle through this and see how it goes.
> Regards,
> Dale
> On Oct 5, 2:19 pm, Benjamin Wright <> wrote:
> > Also... if you have the base protos... why can't you simple compile
> > the Java code for working with them?
> > protoc --java_out=./gen-src myproto.proto
> > On Oct 5, 1:12 pm, Dale Durham <> wrote:
> > > Hi All,
> > > I am fairly new to protobufs, so please bear with me. I am receiving
> > > protobuf messages that were compiled for C++ and I need to read them
> > > in Java. They are created WITHOUT descriptors by the provider and I
> > > cannot change that but I do have access to the base .proto files that
> > > the messages were based on.
> > > My questions are:
> > > 1) What is the best/fastest way to generate the file descriptor(s)
> > > into Java? This should be equal to calling importer.import in C++
> > > based on what I have read.
> > > 2) I assume that question 1 will involve a call out to protoc from
> > > Java. If so, how should that look in general and what command/options
> > > should be used? My goal is to get the file descriptor, after which I
> > > can get everything else from within Java
> > > 3) Is there any way to do this without the protoc callout? I am pretty
> > > sure there is not, but since I am here, I'll ask.
> > > I should mention that I can already get the routing key from within
> > > Java without the descriptor, so I can parse that to determine what
> > > base proto file that I need the descriptor for.
> > > Thanks in advance,
> > > Dale

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to