Protobuf / Java&Go / ParseFrom inconsistent behavior

[Konstantin Chukhlomin]

Hi everyone,

I've found something which I think either wrong or feature.

Say, I have a proto file with definitions:

message Article {
  message PrintData {
    int32 page = 1;
    bool is_published = 2;
    string section = 3;
    string column = 4;
  }

  string title = 1;
  PrintData print_data = 2;
  string kicker = 3;
}

message Image {
  string caption = 1;
  string author = 2;
  int32 width = 3;
}

And then, using Java code I'm filling all the fields in Article, converting it to bytes array and trying to decode it to the Image. Expecting some error, but:

Article article = Article.newBuilder()
        .setTitle("TITLE")
        .setPrintData(
                Article.PrintData.newBuilder()
                        .setPage(1)
                        .setIsPublished(true)
                        .setSection("NEWS")
                        .setColumn("Review")
        )
        .setKicker("BOOM")
        .build();

byte[] bytes = article.toByteArray();

try {
    Image image = Image.parseFrom(bytes);

    System.out.println("Caption: " + image.getCaption()); // TITLE
    System.out.println("Author: " + image.getAuthor()); // NEWS" Review
    System.out.println("Width: " + image.getWidth()); // 0

} catch (InvalidProtocolBufferException e) {
    e.printStackTrace();
}

At the same time, same example failing in Go (which is expected): bad wiretype for field assets.Image.Width: got wiretype 2, want 0.

I wonder if you know answers on these questions:

1) Should go and Java libraries behaviors be the same?

2) Should Java throw exception when Protobuf fields and not compatible?

3) Is it ok that image.author for all strings content from article.print_data?

Code samples (try it yourself):

https://github.com/chuhlomin/proto-java - Message definition and Java check

https://github.com/chuhlomin/proto-go - Go

Additional information:

I've used znly/protoc docker image to generate Go classes from Protobuf.

$ java -version                                                                                                                                                                                                                                                       

java version "1.8.0_101"

Java(TM) SE Runtime Environment (build 1.8.0_101-b13)

Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

$ go version

go version go1.7.1 darwin/amd64

Thanks.

[Jisi Liu]

Parsing the bytes from a valid protobuf wireformat into a unmatched type shouldn't cause parsing failures. Those unrecognized fields should be kept in the unknown fields and should be able to serialize back. Java implementation enforces roundtrip to be lossless.

I'm not familiar with the Go implementation. It seems to treat unrecognized fields differently. The spec doesn't require that all the implementations follow a defined behavior though.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.