kotlin support request

[MartinDong]

please support convert to kotlin

[liujisi]

Right now it is not planned. We recommend using the Java bindings instead given the interoperability, mostly due to the code size bloat when both kotlin and Java are generated in the same app. Will keep this posted when anything changes.

[saturnism]

Kotlin support would be so much better than the current Java builders. :)

[banshee]

Don't forget that Kotlin can compile to non-jvm environments, so just saying 'use java' actually doesn't solve the kotlin problem.

[xenomachina]

If a Kotlin code generator is ever created, it would be great if "oneofs" were turned into sealed classes, rather than having the "*Case" enum.

Also, given how nice null handling is in Kotlin, I wish optional fields could simply be implemented as nullable properties, rather than having the separate "has*" methods.

[christophsturm]

Btw kotlinx.serialization supports protobuf already without any code generation.

_{Sent with GitHawk}

[banshee]

@christophsturm that's interesting, but it doesn't seem like it really addresses the issue. The problem is that you usually start with a .proto file that you really do want to use for code generation, and it looks like there's only partial support for protobuf anyway - Kotlin/kotlinx.serialization#67.

[christophsturm]

yes it has a different focus and i would love to see kotlin code generation in protobuf.

[cretz]

I am toying around with implementing this.

The ideal situation would be to generate all the required data classes (yes, that means immutable and sealed hierarchies for oneofs) and abstract the sizing, marshalling, and unmarshalling via multiplatform expect/actual classes and defer to existing protobuf serialization code for the three primary targets (JVM, JS, native). Maybe could have hand written serialization, but the existing language impls are highly optimized, especially in the JVM case. Also, for protoc-gen-kotlin, I am bootstrapping with the JVM impl for now but once complete, I am planning on it actually using Kotlin native so it can ship as a single binary (so I'm not using KotlinPoet). I am leaving enumerates open ended as data classes w/ a single int value and the known values as vals on the companion object. I may only support proto3 at first, we'll see.

I will update if/when complete.

[cretz]

Initial version complete: https://github.com/cretz/pb-and-k. I'll broadcast to Kotlin forum and/or Reddit tomorrow so no need to clutter up this issue discussing. It only has basic features now, but I'll implement more if the project becomes popular.

[daudrain]

An another projet looks promising kroto-plus

[lowasser]

This is a project we are (and specifically I am) working on for Google, with an unstable prototype landing in open source sometime in the late Q2-early Q3 range.

Some specifics, just to be clear:

• We're initially focusing on building extensions atop the generated Java APIs. A major goal of Kotlin is to support incremental migration of existing Java projects without compatibility hassles; we would intend the same approach here. Down the line, we might investigate generating pure Kotlin, but it would be API compatible with the generated Java APIs.
• Oneofs can't be sealed without breaking on future additions to the oneof, which are supposed to be compatible changes. I think we'll be generating something that "looks like" the sealed class would, except for the sealed keyword.
• We're still discussing nullable representations of optional fields.

[jeremiemartinez]

@lowasser interesting! Can we expect data class generation rather Java builders?

[lowasser]

Neither. Data classes as in data class have difficult conflicts with ways protos are supposed to be able to evolve forward-compatibly. (For example, new fields can be inserted "between" old fields.) We're thinking in terms of DSLs:

myMessage {
   field1 = 5
   field2 = "foobar"
}

...which is not actually that different, all things considered, from

MyMessage(
  field1 = 5, 
  field2 = "foobar"
)