Invoer (.proto-schema)

Uitvoer (Kotlin)

Wat deze tool doet

Je hebt een Protocol Buffers-schema — misschien van het backend-team, misschien van een API-contract van een derde — en een Kotlin-codebase die er getypeerde vormen voor nodig heeft. Of een Android-app die met een gRPC-backend praat, of server-side Kotlin dat JSON-gecodeerde Protobuf-messages parseert. De volledige grpc-kotlin-codegen-pipeline opzetten is overkill als je alleen de data-class-vormen nodig hebt — plakken, kopiëren, neerzetten.

De type-mapping volgt Kotlin-idiomen: string → String, bool → Boolean, bytes → ByteArray, int32/sint32/fixed32 → Int, int64/sint64/fixed64 → Long, double → Double, float → Float. repeated T wordt List<T> met default emptyList(); map<K, V> wordt Map<K, V> met default emptyMap(). Enkelvoudige geneste message-velden zijn nullable (?) met default null — past bij de has-value-semantiek van proto3.

Veldnamen worden van snake_case in de proto naar camelCase in Kotlin (order_id → orderId) omgezet — de standaard Kotlin-codeerconventie volgens de officiële Kotlin-stijl. Klasse- en enum-namen blijven PascalCase. Elke enum wordt een enum class met een Int-backingwaarde. De conversie draait volledig in je browser — je .proto verlaat de pagina nooit.

Hoe je het gebruikt

Drie stappen. De uitvoer is plak-klaar Kotlin.

Plak je .proto-schema

Laat het schema in de linker editor vallen. syntax = "proto3"; bovenaan is prima maar optioneel. Geneste message-blokken, enum-declaraties, oneof, map<K, V> en veld-opties worden allemaal afgehandeld.

Kotlin-codeerconventies geven de voorkeur aan camelCase voor properties — de converter doet dat voor je. Wil je de oorspronkelijke snake_case-namen liever houden (sommige serialisatiebibliotheken matchen veldnamen exact), gebruik dan zoek-en-vervang in de uitvoer.

Lees de Kotlin-uitvoer

Rechts: elke message wordt een data class met defaultwaarden voor elke property. Elke enum wordt een enum class(val value: Int) zodat je het wire-formaat heen-en-weer kunt serialiseren. Alleen op rootniveau (geen nesting) — makkelijk in één bestand te zetten of te splitsen.

Hang het in je project

Zet het bestand in je project, voeg een package-declaratie toe en importeer. Voor echte gRPC-code op Android of de JVM wil je nog steeds grpc-kotlin-codegen draaien om de marshal-methoden en stubs te krijgen. Deze uitvoer is voor getypeerde JSON-afhandeling, struct-schetsen en reviews.

Wanneer dit echt tijd bespaart

Android-types schetsen vanuit een backend-.proto

Je Android-app praat met een gRPC-backend. Het backend-team is eigenaar van de .proto. Je wilt de data-class-vormen om je view models te typeren zonder al codegen op te tuigen. Plak, dump in Models.kt, je bent getypeerd.

Server-side Kotlin dat JSON-gecodeerde Protobuf parseert

Je server-side Kotlin (Ktor / Spring Boot) verwerkt JSON dat de proto3-JSON-codering volgt. Je hebt data classes nodig die matchen. Plak de .proto, kopieer de Kotlin-uitvoer, hang het aan de serializer van je keuze.

Een Protobuf-API-wijziging reviewen

Een teamgenoot heeft velden aan een message toegevoegd. Plak de nieuwe .proto, diff de Kotlin-uitvoer tegen je huidige Models.kt, laat een gerichte review achter zonder de hele toolchain op te starten.

Eenmalige scripts en snelle prototypes

Een Kotlin-scriptje van 50 regels dat een gRPC-gateway aanslaat. grpc-kotlin en protoc daarvoor opzetten is overkill. Genereer hier de data classes en zet ze erin.

Veelgestelde vragen

Is dit een vervanger voor protoc-gen-kotlin?

Nee. Echte codegen produceert marshal-/unmarshal-methoden, descriptors en de gRPC-stubs. Deze tool zendt alleen de data-class-vormen uit. Voor productie-gRPC-code draai je grpc-kotlin. Gebruik dit voor schetsen, JSON-parsing, reviews en eenmalige scripts.

Waarom zijn enkelvoudige message-velden nullable?

In proto3 hebben message-velden een "has value"-semantiek — ze kunnen ongezet zijn. Het schoonste Kotlin-equivalent is een nullable property met default null. Als je weet dat je data deze velden altijd vult, haal de ? en de default eruit — rechttoe-rechtaan zoek-en-vervang.

Hoe worden uint32 en uint64 afgehandeld?

Beide mappen op signed types (Int en Long). Kotlin heeft sinds 1.5 stabiele UInt- en ULong-types, maar de signed varianten zijn compatibeler met bestaande serialisatiebibliotheken en de meeste Android-codebases. Heb je specifiek de unsigned varianten nodig, vervang ze dan in de uitvoer.

Hoe worden enums uitgegeven?

Elke enum wordt een enum class WithValue(val value: Int) zodat je de integer van het wire-formaat kunt behouden. Elke waarde krijgt de oorspronkelijke proto-naam (bijv. ORDER_STATUS_PENDING) — Kotlin-enum-entries zijn per conventie toch al SCREAMING_SNAKE_CASE, dus dat past.

Hoe worden veldnamen omgezet?

snake_case → camelCase volgens Kotlin-codeerconventies. order_id wordt orderId, customer_name wordt customerName. Klasse- en enum-namen blijven PascalCase zoals in de proto.

Behandelt het geneste messages?

Ja — geneste message-blokken worden in de uitvoer afgevlakt naar data class-declaraties op rootniveau. Dat houdt het bestand makkelijk leesbaar en eenvoudig op te splitsen in meerdere bestanden. Heb je liever Kotlins geneste klassen, wikkel ze dan zelf in.

Gerelateerde tools

Werk je met Protobuf en Kotlin, dan passen deze er goed bij:

Protobuf-naar-Kotlin-converter