Eingabe (.proto-Schema)

Ausgabe (Java)

Was dieses Tool macht

Du hast ein Protocol-Buffers-Schema und einen Java-Service, der diese Nachrichten konsumiert — vielleicht über gRPC, vielleicht über JSON über HTTP. Den offiziellen protoc mit dem Java-Plugin laufen zu lassen liefert dir Klassen im Builder-Pattern — toll für Produktion, aber zu schwer fürs Skizzieren, Prototyping oder das händische Mappen von JSON auf ein POJO. Dieser Konverter gibt schlichte Java-Klassen aus — public Felder, sinnvolle Defaults, eine Klasse pro Nachricht, separate Typen für Enums.

Das Type-Mapping orientiert sich daran, wie handgeschriebenes Java in der Praxis aussieht: string → String, bool → boolean, int32/sint32/sfixed32 → int, int64/sint64/sfixed64 → long, double → double, float → float, bytes → byte[]. Java hat keine vorzeichenlosen numerischen Typen, also fallen uint32/fixed32 auf int und uint64/fixed64 auf long — passt für die meisten Fälle; wenn du das oberste Bit wirklich brauchst, nutze Integer.toUnsignedLong an der Grenze. repeated T wird zu List<T>, map<K, V> wird zu Map<K, V>, beide aus java.util.

Feldnamen werden von snake_case (Protobuf-Konvention) auf camelCase (Java-Konvention) umgesetzt — passend zu dem, was protoc tun würde, und zu dem, was das proto3-JSON-Mapping verwendet. Enums werden zu top-level public enum-Typen, wobei der Integer-Wire-Wert in einem final-Feld erhalten bleibt, damit du jederzeit zu protoc-generiertem Code wechseln und Round-Trippen kannst. Verschachtelte Nachrichten werden zu Top-Level-Klassen geflattet, damit jede einzelne in eine eigene Datei wandern kann, wenn du die Ausgabe aufteilst. Alles läuft im Browser — dein Schema verlässt die Seite nicht.

So nutzt du es

Drei Schritte. Die Ausgabe ist bereit, in ein Java-Projekt zu wandern.

Füge dein .proto-Schema ein

Lass das Schema in den linken Editor fallen. syntax = "proto3"; oben ist OK, aber optional. Der Parser kommt mit verschachtelten message-Blöcken, enum-Deklarationen, oneof, map<K, V> und Feldoptionen klar. import-Direktiven werden erkannt, aber übersprungen — füge importierte Typen inline ein, falls du sie brauchst.

Die Feldnamen-Umwandlung ist automatisch: order_id in der .proto-Datei wird in Java zu orderId. Nachrichten- und Enum-Namen bleiben wie sie sind (schon PascalCase).

Lies die Ausgabe

Rechts: ein einzelner .java-Block, alle Enums zuerst, dann alle Klassen in Deklarationsreihenfolge. Jede Klasse hat public Felder mit Default-Werten für Primitive (0, 0.0, false, ""), und Referenztypen (List, Map, Nachrichtenrefs) bleiben null, bis du sie befüllst. Die Imports java.util.List und java.util.Map werden nur dann hinzugefügt, wenn das Schema sie braucht.

Lass es in dein Projekt fallen

Kopiere jede Klasse in ihre eigene .java-Datei (Java verlangt eine public Klasse pro Datei). Füge eine package-Deklaration hinzu, dann verkable die Klassen mit deinem JSON-Deserialisierer der Wahl — Jackson nimmt public Felder per Default mit, und das proto3-JSON-Mapping nutzt camelCase, also passen die Feldnamen schon. Wenn du Getter/Setter bevorzugst, erledigt IntelliJs "Encapsulate Fields"-Refactoring das mit einem Tastendruck.

Wann das wirklich Zeit spart

Einen Java-Client für einen gRPC-Service skizzieren

Du machst einen Spike eines Java-Clients gegen ein bestehendes gRPC-Backend — vielleicht ein Spring-Boot-Service, vielleicht ein Quarkus — und willst noch nicht das volle protoc-Maven- oder Gradle-Plugin aufsetzen. Schema einfügen, Klassen in src/main/java/dto ablegen, JSON-Antwort mit Jackson deserialisieren, Prototyp ausliefern.

DTOs händisch bauen, die zu einem Proto passen

Dein Team nutzt Protobuf als Source of Truth auf der Leitung, aber der konsumierende Java-Service braucht nur drei oder vier Felder, und du willst keine Message/Builder-Abhängigkeit. Schema einfügen, die Felder löschen, die du nicht brauchst, und du hast ein schlichtes DTO, das eigenständig kompiliert.

Einen Protobuf-API-Wechsel reviewen

Eine Backend-Kollegin hat Felder zu einer Nachricht hinzugefügt. Du willst sehen, wie sich das auf das Java-POJO auswirkt, ohne den Build laufen zu lassen. Neues .proto einfügen, Java-Ausgabe gegen deine aktuellen Klassen diffen, einen fokussierten Review-Kommentar hinterlassen.

Die protoc-generierte Ausgabe gegenchecken

Dein Build verwendet das offizielle protoc-Java-Plugin, das Klassen im Builder-Pattern produziert. Schema hier einfügen für eine saubere Referenz, wie schlichtes Java aussieht — nützlich für Doku, Onboarding oder für Kotlin-Kollegen, die Data Classes bevorzugen.

Häufige Fragen

Wird mein Schema irgendwohin gesendet?

Nein. Parser und Java-Emitter laufen komplett im Browser als JavaScript. Öffne die DevTools und schau in den Network-Tab, während du einfügst — null Requests. Praktisch, wenn dein Schema interne Package-Pfade, Typnamen oder sonst irgendetwas enthält, das du nicht an einen Drittanbieter schicken willst.

Warum public Felder und keine Getter/Setter?

Zwei Gründe. Erstens, die Ausgabe ist als Ausgangspunkt gedacht, den du anpasst — public Felder sind das Kleinste, was kompiliert, und du kannst jederzeit "Encapsulate Fields" in deiner IDE ausführen. Zweitens, der häufigste Konsument ist die Jackson-Deserialisierung, die mit public Feldern out-of-the-box läuft. Wenn du einen Record, einen unveränderlichen Typ oder eine Lombok-@Data-Klasse brauchst, füge die Ausgabe ein und refaktoriere.

Wie werden uint32 und uint64 behandelt?

Java hat keine vorzeichenlosen Integer-Typen, also mappen uint32/fixed32 auf int und uint64/fixed64 auf long. Für Werte, die in den signed Bereich passen, funktioniert das gut; für Werte oberhalb von Integer.MAX_VALUE oder Long.MAX_VALUE siehst du negative Zahlen. Der Standard-Fix ist Integer.toUnsignedLong(x) an der Grenze, oder die arithmetischen Helpers von java.lang.Long zu nutzen — siehe die Java-21-API-Doku für die unsigned Helpers.

Warum sind int64-Felder einfach long, nicht String?

TypeScript und JSON haben eine Präzisionsobergrenze von 53 Bits, also kodiert die proto3-JSON-Spezifikation 64-Bit-Ints als Strings, um Präzision zu erhalten. Javas long ist ein echter 64-Bit-Signed-Integer ohne Präzisionsverlust, also behalten wir den Java-Typ als long. Wenn du JSON deserialisierst, in dem der Server den int64 schon als String kodiert hat, konfiguriere Jackson mit @JsonFormat oder einem Custom-Deserialisierer; der zugrundeliegende Typ muss sich nicht ändern.

Wie werden verschachtelte Nachrichten behandelt?

Jede verschachtelte Nachricht wird zu einer Top-Level-Klasse geflattet. Javas Konvention ist eine public Klasse pro Datei, also sind flache Top-Level-Typen leichter aufzuteilen, wenn du jede Klasse in ihre eigene .java-Datei kopierst. Wenn du lieber static inner classes hättest (der Stil, den protoc ausgibt), füge die Ausgabe ein und schiebe die verschachtelten Klassen ins Innere ihres Parents — die Feldreferenzen nutzen schon den Leaf-Namen und werden auflösen, sobald sie im selben Scope sind.

Sind Felder als optional markiert?

Nein — proto3-Felder haben im Wire-Format immer einen Default, also werden primitive Felder auf ihren Java-Nullwert initialisiert (0, 0.0, false, ""). Referenztypen (List, Map, verschachtelte Nachrichten, byte[]) starten als null; denk daran, sie zu initialisieren, bevor du Elemente hinzufügst. Wenn du explizite Optional<T>-Wrapper willst, ist das ein manueller Schritt.

Kommt es mit oneof klar?

Jedes oneof-Feld wird als reguläres Klassenfeld emittiert. Die Ausgabe erzwingt nicht die "genau eines"-Bedingung, die oneof impliziert — dafür bräuchtest du eine sealed Type-Hierarchie oder einen Runtime-Check, beides passt nicht zu einem schlichten POJO. Wenn du strengere Modellierung willst, nimm die Ausgabe und konvertiere die oneof-Felder in ein sealed Interface mit einem Record pro Fall.

Kann ich diese Klassen mit der offiziellen protobuf-java-Runtime verwenden?

Nicht direkt — die offizielle Runtime erwartet von protoc generierte Klassen mit Builder, parseFrom und dem Rest des com.google.protobuf.MessageOrBuilder-Vertrags. Die Klassen aus diesem Tool sind schlichte POJOs, gedacht für JSON-Serialisierung (Jackson, Gson, Moshi). Für das binäre Wire-Format willst du weiterhin den offiziellen Codegen — siehe das Java-Tutorial fürs Setup.

Protobuf-zu-Java-Konverter