compilation errors in ProtobufJSON

[GoogleCodeExporter]

What steps will reproduce the problem?

When compiling protostuff from eclipse (Version: Helios Service Release 2, 
Build id: 20110218-0911, jdk1.6.0_25), I'm getting compilation errors in 
ProtobufJSON class. 

Method parseFrom(InputStream, Class<B>) has the same erasure 
parseFrom(InputStream, Class<T>) as another method in type ProtobufJSON line 
131 
Method parseFrom(InputStream, Class<T>) has the same erasure 
parseFrom(InputStream, Class<T>) as another method in type ProtobufJSON line 82 
Method parseFrom(JsonParser, Class<B>) has the same erasure 
parseFrom(JsonParser, Class<T>) as another method in type ProtobufJSON line 159 
Method parseFrom(JsonParser, Class<T>) has the same erasure 
parseFrom(JsonParser, Class<T>) as another method in type ProtobufJSON line 111 
Method parseFrom(Reader, Class<B>) has the same erasure parseFrom(Reader, 
Class<T>) as another method in type ProtobufJSON line 145   
Method parseFrom(Reader, Class<T>) has the same erasure parseFrom(Reader, 
Class<T>) as another method in type ProtobufJSON line 96    

Bound mismatch: The generic method parseFrom(InputStream, Class<T>) of type 
ProtobufJSON is not applicable for the arguments (JsonParser, Class<B>). The 
inferred type B is not a valid substitute for the bounded parameter <T extends 
MessageLite> line 137
Bound mismatch: The generic method parseFrom(InputStream, Class<T>) of type 
ProtobufJSON is not applicable for the arguments (JsonParser, Class<B>). The 
inferred type B is not a valid substitute for the bounded parameter <T extends 
MessageLite> line 151

Original issue reported on code.google.com by michal.b...@gmail.com on 7 Jul 2011 at 11:20

[GoogleCodeExporter]

Hi Michael,

Do you have specific requirements on why you can't use protostuff-api, 
protostuff-json and use the protostuff-compiler to generate via 
java_v2protoc_schema?

This module was an early experiment and hasn't been maintained much in place 
for the unified api I mentioned.  The serialized output is basically the same 
(and you get all the other formats for free)

Cheers

Original comment by david.yu...@gmail.com on 7 Jul 2011 at 5:11

[GoogleCodeExporter]

I don't need protostuff-model-json at all, protostuff-api, protostuff-json 
works for me just fine. I'm just reporting compilation error from eclipse. 
Anyway, it can be easily fixed by altering method names ( for example <B 
extends Builder> B parseFrom(...) -> <B extends Builder> B parseFromB(...) )

Original comment by michal.b...@gmail.com on 8 Jul 2011 at 5:35

[GoogleCodeExporter]

I'm using galileo.  Both eclipse and maven2 had no complaints.
I dunno whats up with the different behaviors of the compilers.

Original comment by david.yu...@gmail.com on 8 Jul 2011 at 6:57

• Changed state: Accepted

[GoogleCodeExporter]

I have the same problem with Eclipse - Indigo Service Release 1. 
I can compile from command line - I use OpenJDK 6.b22_1.10.5

Its odd but seems to be a "bug" in sun/oracle's compiler. 

Basically the method pairs

public final <B extends Builder> B parseFrom(XXX x, Class<B> type) throws 
IOException
public final <B extends MessageLite> B parseFrom(XXX x, Class<B> type) throws 
IOException

Have the same type erasure so in bytecode they will probably become something 
like if they were

public final Builder parseFrom(XXX x, Class type) throws IOException
public final MessageLite parseFrom(XXX x, Class type) throws IOException

In Java Language Spec the return type does not take part in method signature - 
so they are the same.
In bytecode however methods like these (with different return types) will be 
valid and can exist - that's why it works at runtime.

This seems to be an old bug in java compiler 5 and 6 - 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182950

Probably fixed in JDK 7  thats why the new versions of eclipse does not accept 
this.
This one is a bug report from eclipse 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=320514
which states that similar code does not compile in JDK 7. 
Have not tried it myself with JDK 7 but probably it will be best if the 
signatures change

I propose

public final <B extends Builder> B parseBuilderFrom(XXX x, Class<B> type) 
throws IOException
public final <B extends MessageLite> B parseMessageFrom(XXX x, Class<B> type) 
throws IOException

like the append methods.

Since writeTo and mergeTo methods are void there will no be problem with them, 
but for consistensy consider renaming them too.

Original comment by tsac...@gmail.com on 20 Jan 2012 at 11:17