Yes, I tried to use the reflection API, but this doesn't seem right to me
because I have to mantain 3 classes for the same entity. When I add a new
attribute I'll have to update 3 files! I know I really cannot use JPA with
the java code generated by protoc, but using the reflection API the best
way? I was used to a java-only world where I could automatically transform
my objects into xml messages having only one class representing one entity
for all project.
About my try on the reflection API, I did not succed and I posted one
question about it, could you please help me? I understood that I had to use
the protobuf reflection together with java reflection:
Thank you for your reply.
On Tue, Sep 14, 2010 at 3:19 PM, Kenton Varda <ken...@google.com> wrote:
> I'm not all that familiar with JPA, but my guess is that applying JPA to a
> protocol buffer type is going to be much less efficient than using
> protobuf's native encoding. So you probably want to be serializing your
> protobufs with .toByteArray() and then persisting that.
> Failing that, you might want to look at the protobuf reflection API (not to
> be confused with java reflection) to see if it might be part of a solution:
> maybe you could call message.getAllFields() and then feed the data into JPA
> On Mon, Sep 13, 2010 at 12:09 PM, roberto_sc <roberto.cal...@gmail.com>wrote:
>> I have a basic question about how to organize my project.
>> I have a client running C# code, a server running Java code and I
>> intend to use protocol buffers to exchange data.
>> I thought I could use the .proto file to describe the classes of my
>> datamodel and generate .java and .cs and then use these generated src
>> as my datamodel. But protoc generate code for message exchange and
>> cannot be edited, for example, I cannot generate java code for my
>> Person class and add the annotations to persist using JPA.
>> So, the question is, do I have to mantain 3 files - .java, .cs
>> and .proto - that represent the same thing?
>> 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
>> For more options, visit this group at
virtus in medium est
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
For more options, visit this group at