Seems like ProtobufHttpMessageConverter supports only full-featured protobuf Message inheritors. Is it possible to add MessageLite support for LITE_RUNTIME protobuf usage?

https://github.com/spring-projects/spring-framework/blob/b5529f3f2bcf69c89a0a6a52c4f6b0034dc7f61e/spring-web/src/main/java/org/springframework/http/converter/protobuf/ProtobufHttpMessageConverter.java#L170-L173

  • Spring: 2.2.1.RELEASE
  • Protobuf: 3.10.0

Comment From: rstoyanchev

Likewise for ProtobufDecoder and ProtobufEncoder.

Comment From: bclozel

@dummyco We're working on this issue for the upcoming milestone.

As far as I understand, the Message interface extends MessageLite, which makes it difficult to support in a single HttpMessageConverter<?>. We could introduce a breaking change and only support MessageLite types, but the lite variant offers less features and serialization formats: the lite variant doesn't support JSON as a serialization format and messages themselves don't support descriptors nor reflection.

The MessageLite implementation is both in "com.google.protobuf:protobuf-java" and "com.google.protobuf:protobuf-javalite"; I guess the difference is mainly for clients (smaller library size, reflection support...) and that servers will depend on "com.google.protobuf:protobuf-java".

So the difference really comes from the code generation phase. Previously there was a LITE_RUNTIME option that you could use in proto files, it's now deprecated and there is a dedicated command line option on the protoc binary (protoc --java_out=lite:/folder).

Because of the java type and MIME type differences, I'm going to introduce new ProtobufLite{MessageConverter,HttpMessageConverter,Decoder,Encoder}. I'll introduce a shared abstract hierarchy when it makes sense.

Pinging @sdeleuze to get his opinion on this approach.

Comment From: bclozel

After discussing this feature with other team members, I'm going to decline this feature request. It seems the situation evolved since this issue was created.

As far as I understand, supporting MessageLite in codecs would be useful in cases where the proto definition files contain the optimize_for = LITE_RUNTIME option. Generating protobuf classes from such definitions previously created classes extending the MessageLite hierarchy (which is totally independent from the regular Message one). This could also be useful if the Spring application consumes a jar with the generated classes in it.

Now, the optimize_for = LITE_RUNTIME option is not effective anymore, the choice of generating Lite or regular message classes is done at generation time. This means that mobile apps can generate MessageLite classes and the server Message classes, using the same proto file.

Since the Message and MessageLite hierarchies are different and don't have the same API guarantees, I think that using Message on the server side is preferable anyway.

Finally, implementing that feature requires to duplicate all codecs and converters in order to have a specific variant for MessageLite. This means that we would also need to register twice the number of codecs and also refine their supports condition so that they don't step on each other.

As a result, I'm closing this issue for now, but we can reconsider this later. Community members are free to comment here and add more information about the use cases and limitations of our current approach.

Comment From: smelfungus

@bclozel, thank you for the time and effort taken to review this feature request. That decision is reasonable, server-side Message + client-side MessageLite approach sounds great.