Eingabe (.proto-Schema)

Ausgabe (Kotlin)

Was dieses Tool macht

Du hast ein Protocol Buffers-Schema — vielleicht vom Backend-Team, vielleicht aus einem Drittanbieter-API-Vertrag — und eine Kotlin-Codebasis, die typisierte Formen dafür braucht. Entweder eine Android-App, die ein gRPC-Backend ruft, oder serverseitiges Kotlin, das JSON-kodierte Protobuf-Messages parst. Die volle grpc-kotlin-Codegen-Pipeline aufzusetzen ist Overkill, wenn du nur die Data-Class-Formen brauchst — einfügen, kopieren, einfügen.

Das Type-Mapping folgt Kotlin-Idiomen: string → String, bool → Boolean, bytes → ByteArray, int32/sint32/fixed32 → Int, int64/sint64/fixed64 → Long, double → Double, float → Float. repeated T wird zu List<T> mit Default emptyList(); map<K, V> wird zu Map<K, V> mit Default emptyMap(). Singuläre verschachtelte Message-Felder sind nullable (?) mit Default null — passt zur has-value-Semantik von proto3.

Feldnamen werden von snake_case im Proto zu camelCase in Kotlin (order_id → orderId) konvertiert — die Standard-Kotlin-Codingkonvention laut offiziellem Kotlin-Style. Klassen- und Enum-Namen bleiben PascalCase. Jedes Enum wird zu einer enum class mit einem Int-Backing-Wert. Die Konvertierung läuft komplett in deinem Browser — dein .proto verlässt nie die Seite.

So benutzt du es

Drei Schritte. Die Ausgabe ist einfügbares Kotlin.

Füge dein .proto-Schema ein

Lass das Schema in den linken Editor fallen. syntax = "proto3"; oben ist ok, aber optional. Verschachtelte message-Blöcke, enum-Deklarationen, oneof, map<K, V> und Feld-Optionen werden alle behandelt.

Kotlin-Codingkonventionen bevorzugen camelCase für Properties — der Konverter erledigt das für dich. Wenn du die ursprünglichen snake_case-Namen lieber hättest (manche Serialisierungsbibliotheken matchen Feldnamen exakt), nutze Suchen-Ersetzen in der Ausgabe.

Lies die Kotlin-Ausgabe

Rechts: jede Message wird zu einer data class mit Default-Werten für jede Property. Jedes Enum wird zu einer enum class(val value: Int), sodass du das Wire-Format hin- und zurück serialisieren kannst. Nur Top-Level (keine Verschachtelung) — leicht in eine Datei zu schmeißen oder aufzuteilen.

In dein Projekt einbinden

Datei in dein Projekt legen, eine package-Deklaration ergänzen und importieren. Für echten gRPC-Code auf Android oder der JVM willst du immer noch grpc-kotlin-Codegen laufen lassen, damit du die Marshal-Methoden und Stubs bekommst. Diese Ausgabe ist für typisiertes JSON-Handling, Struktur-Skizzen und Reviews.

Wann das wirklich Zeit spart

Android-Typen aus einem Backend-.proto skizzieren

Deine Android-App spricht mit einem gRPC-Backend. Das Backend-Team besitzt das .proto. Du willst die Data-Class-Formen, um deine ViewModels zu typisieren, ohne schon Codegen aufzusetzen. Einfügen, in Models.kt ablegen, fertig.

Serverseitiges Kotlin parst JSON-kodiertes Protobuf

Dein serverseitiges Kotlin (Ktor / Spring Boot) konsumiert JSON, das der proto3-JSON-Kodierung folgt. Du brauchst passende Data-Classes. .proto einfügen, Kotlin-Ausgabe kopieren, in den Serializer deiner Wahl stecken.

Eine Protobuf-API-Änderung reviewen

Ein Teamkollege hat einer Message Felder hinzugefügt. Neues .proto einfügen, Kotlin-Ausgabe gegen dein aktuelles Models.kt diffen, ein fokussiertes Review hinterlassen — ohne die volle Toolchain hochzufahren.

Einmalige Skripte und schnelle Prototypen

Ein 50-Zeilen-Kotlin-Skript, das ein gRPC-Gateway anschießt. grpc-kotlin und protoc nur dafür aufzusetzen ist Overkill. Generiere die Data-Classes hier und wirf sie rein.

Häufige Fragen

Ist das ein Ersatz für protoc-gen-kotlin?

Nein. Echtes Codegen produziert Marshal-/Unmarshal-Methoden, Descriptors und die gRPC-Stubs. Dieses Tool gibt nur die Data-Class-Formen aus. Lass für produktiven gRPC-Code grpc-kotlin laufen. Nutze das hier für Skizzen, JSON-Parsing, Reviews und einmalige Skripte.

Warum sind singuläre Message-Felder nullable?

In proto3 haben Message-Felder eine "has value"-Semantik — sie können ungesetzt sein. Das sauberste Kotlin-Äquivalent ist eine nullable Property mit Default null. Wenn du weißt, dass deine Daten diese Felder immer befüllen, lass das ? und den Default weg — simples Suchen-Ersetzen.

Wie werden uint32 und uint64 behandelt?

Beide werden auf vorzeichenbehaftete Typen (Int und Long) gemappt. Kotlin hat seit 1.5 stabile UInt- und ULong-Typen, aber die vorzeichenbehafteten passen besser zu existierenden Serialisierungsbibliotheken und den meisten Android-Codebases. Wenn du die unsigned-Varianten konkret brauchst, tausch sie in der Ausgabe aus.

Wie werden Enums ausgegeben?

Jedes wird zu einer enum class WithValue(val value: Int), sodass du den Wire-Format-Integer erhalten kannst. Jeder Wert bekommt den ursprünglichen Proto-Namen (z. B. ORDER_STATUS_PENDING) — Kotlin-Enum-Einträge sind konventionell ohnehin SCREAMING_SNAKE_CASE, das passt also.

Wie werden Feldnamen konvertiert?

snake_case → camelCase gemäß Kotlin-Codingkonventionen. order_id wird zu orderId, customer_name wird zu customerName. Klassen- und Enum-Namen bleiben PascalCase wie im Proto.

Verarbeitet es verschachtelte Messages?

Ja — verschachtelte message-Blöcke werden in der Ausgabe zu Top-Level-data class-Deklarationen abgeflacht. Das hält die Datei lesbar und leicht in mehrere Dateien splittbar. Wenn du Kotlins verschachtelte Klassen lieber hast, verpacke sie von Hand.

Protobuf-zu-Kotlin-Konverter