proto3 Working Document

As kicked off by issue 210, here’s what we need for proto3:

• Forbid optional / required labels
• First enum value with tag 0 (#575)
  • Default Java enums to that value
  • Forbid null for Java enums
• Any
  • support in parser (TODO oldergod: update)
  • support in schema
  • code gen and runtime API (requires google/protobuf/any.proto)
  • serialization & deserialization
• map
  • support in parser
  • support in schema (#578)
  • code gen and runtime API (#596)
  • serialization & deserialization (#596)
• Timestamp and Duration (#1382)
  • code gen and runtime API (timestamp.proto, duration.proto)
  • serialization & deserialization
• Packed is default for repeated scalars (#1383)
• reserved
  • support in parser (#548)
  • support enforcement in schema (#283)
• stream keyword for RPC response types (#282, #580)
• No extensions unless it’s a custom option. (#1384)
• ~No unknown fields~ They got reverted in 3.5.
• Forbid user-defined default values (#1385)
• Scalars become non-nullable, but message fields remain nullable. (#1386)
  • Test case: empty string, default enum, 0 int in a repeated field should all be encoded.
  • Test case: map entries that have default values.
• Support in Java.
  • Crash if we pass a null to a non-nullable type (like int32)
  • Default Java strings to “”
  • Forbid null for Java strings
• Support in Gson.
• Tests for Gson and proto3.
• Tests for Java and proto3.
• AnyMessage documentation. (@oldergod)
• Wrappers. (@swankjesse and @oldergod)
  • Runtime.
  • JSON.
• JSON support.
  • Moshi release for custom keys (@swankjesse to cut Moshi release)
  • MapAdapters. (@swankjesse)
    • Unignore WireJsonTest#wrappers().
    • Map values in Gson (@swankjesse).
• Create a doc to list differences we took in designing our generated code differently from Google. (@oldergod)
• Proto2 and Proto3 interoperability tests. (@oldergod)
• Remove proto3 unsupported option. (@oldergod)
• Forbid usage for proto2 enums in proto3 messages. (@oldergod)

Goal: All done September 1?

[oldergod]

We’re aiming at releasing a RC in 2 weeks.

[garyp]

@sweetbot You might want to check out https://github.com/streem/pbandk (disclaimer: I’m one of the developers). It supports proto3 and generates Kotlin multiplatform code (currently supports Kotlin/JVM and Kotlin/JS; Kotlin/Native is still to do). It’s not as mature as Wire, but we’d love some community contributions! We use it in production and all of the basic protobuf features are supported.

Also, I have the utmost respect for the Wire library and its authors. We probably would have ended up using Wire if proto3 support had been available. I’m only mentioning an alternative here because someone asked. There’s a lot of similarity between the two libraries, but there are also places where we’ve made different design decisions, especially in how to best represent things in Kotlin.