[protobuf] Compile warnings in Java due to no serialVersionUID

[robfig]

Hello,
Protoc generates Java classes that produce warnings upon compilation,
of the form:

warning: [serial] serializable class
com.example.ExampleApp.ExampleMessage has no definition of
serialVersionUID

It looks like it should be easy to fix this problem (e.g. just add
private static final long serialVersionUID = 1L; to each class
definition). I haven't yet investigated whether or not it's possible
to make this change using plugins, but it seems like something that
should be fixed in protoc.

Curiously, I haven't been able to find any other report of this issue,
so it's also a possibility that something is messed up for me in
particular. I run protoc using ant as follows:

<target name="protoc" if="protoc.exists" depends="init">
<apply executable="protoc" failifexecutionfails="true"
relative="true" osfamily="windows">
<arg value="-I=src"/>
<arg value="--java_out=src"/>
<fileset dir="." includes="src/**/*.proto" />
<mapper type="glob" from="*.proto" to="*.java"/>
</apply>
</target>

Everything works great, except for the compile warnings. I use the
latest protoc.

$ protoc --version
libprotoc 2.3.0

Any ideas?
Thanks,
Rob

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

[Kenton Varda]

Generated protobuf classes as of version 2.3.0 do not implement Serializable.  A change to support this was recently submitted against the version of the code in our internal repository, but I have not yet had the chance to port it to the cross-platform version (I will do so sometime before the next release).  As it turns out, the internal version has the bug you describe.  Are you a Google employee?

[Rob Figueiredo]

No, I'm not.

That is a good clue though.  We include other Google libraries in our build, so I wonder if one of those libraries has the internal GeneratedMessage class you speak of...

Yep.

$ jar tvf jars/closure-compiler-r182.jar  | grep protobuf
     0 Tue Apr 13 19:27:56 EDT 2010 com/google/protobuf/
  1059 Tue Jan 01 00:00:02 EST 1980 com/google/protobuf/AbstractMessage$1.class
 24100 Tue Jan 01 00:00:02 EST 1980 com/google/protobuf/AbstractMessage$Builder.class
  5439 Tue Jan 01 00:00:02 EST 1980 com/google/protobuf/AbstractMessage.class
  1488 Tue Jan 01 00:00:02 EST 1980 com/google/protobuf/AbstractMessageLite$Builder$LimitedInputStream.class
  9599 Tue Jan 01 00:00:02 EST 1980 com/google/protobuf/AbstractMessageLite$Builder.class
  2440 Tue Jan 01 00:00:02 EST 1980 com/google/protobuf/AbstractMessageLite.class
 ...

Thanks for helping us track this down.  I guess the solution is to list protobuf-java-2.3.0.jar first in the classpath until closure compiler updates their jar.  Yuck.

Cheers,
Rob

[Kenton Varda]

Ouch, that's really annoying!  The internal copy could easily be out-of-sync with the external one, meaning your protoc-generated code would not work with closure's version and closure's protoc-generated code would not work with the public version.  In that case it would be impossible for you to load your code and closure's in the same class loader.

Libraries that google releases publicly really need to either use one of the official protobuf releases, or relocate the protobuf code to a private package.  Unfortunately some teams don't understand this.  :/