Entrée (schéma .proto)

Sortie (Kotlin)

Ce que fait cet outil

Tu as un schéma Protocol Buffers — peut-être de l'équipe backend, peut-être d'un contrat d'API tierce — et une codebase Kotlin qui a besoin de formes typées correspondantes. Soit une appli Android qui parle à un backend gRPC, soit du Kotlin côté serveur qui parse des messages Protobuf encodés en JSON. Mettre en place tout le pipeline de codegen grpc-kotlin est démesuré si tu ne veux que les formes de data class — colle, copie, place.

Le mapping de types suit les idiomes Kotlin : string → String, bool → Boolean, bytes → ByteArray, int32/sint32/fixed32 → Int, int64/sint64/fixed64 → Long, double → Double, float → Float. repeated T devient List<T> avec default emptyList() ; map<K, V> devient Map<K, V> avec default emptyMap(). Les champs de message imbriqué singuliers sont nullable (?) avec default null — ça colle à la sémantique has-value de proto3.

Les noms de champs passent de snake_case dans le proto à camelCase en Kotlin (order_id → orderId) — la convention de codage Kotlin standard d'après le style officiel Kotlin. Les noms de classe et d'enum restent en PascalCase. Chaque enum devient une enum class avec un Int de valeur de support. La conversion tourne entièrement dans ton navigateur — ton .proto ne quitte jamais la page.

Comment l'utiliser

Trois étapes. La sortie est du Kotlin prêt à coller.

Colle ton schéma .proto

Mets le schéma dans l'éditeur de gauche. syntax = "proto3"; en haut, c'est bien mais facultatif. Les blocs message imbriqués, déclarations enum, oneof, map<K, V> et options de champ sont tous gérés.

Les conventions Kotlin préfèrent camelCase pour les propriétés — le convertisseur le fait pour toi. Si tu préfères les noms d'origine en snake_case (certaines libs de sérialisation matchent les noms de champs à l'identique), fais un find-replace dans la sortie.

Lis la sortie Kotlin

À droite : chaque message devient une data class avec des valeurs par défaut pour chaque propriété. Chaque enum devient une enum class(val value: Int) pour que tu puisses faire le round-trip du format wire. Top-level uniquement (pas d'imbrication) — facile à mettre dans un seul fichier ou à découper.

Branche-le dans ton projet

Mets le fichier dans ton projet, ajoute une déclaration package, et importe. Pour du vrai code gRPC sur Android ou la JVM tu voudras quand même lancer le codegen grpc-kotlin pour avoir les méthodes marshal et les stubs. Cette sortie sert au handling JSON typé, aux esquisses de struct et aux revues.

Quand ça fait vraiment gagner du temps

Esquisser des types Android depuis un .proto backend

Ton appli Android parle à un backend gRPC. L'équipe backend possède le .proto. Tu veux les formes de data class pour typer tes view models sans encore mettre en place le codegen. Colle, mets dans Models.kt, te voilà typé.

Kotlin côté serveur qui parse du Protobuf encodé en JSON

Ton Kotlin côté serveur (Ktor / Spring Boot) consomme du JSON qui suit l'encodage JSON proto3. Tu as besoin de data classes qui matchent. Colle le .proto, copie la sortie Kotlin, branche-la sur le sérialiseur de ton choix.

Reviewer un changement d'API Protobuf

Un coéquipier a ajouté des champs à un message. Colle le nouveau .proto, fais un diff de la sortie Kotlin contre ton Models.kt actuel, laisse une revue ciblée sans relancer toute la toolchain.

Scripts ponctuels et proto rapides

Un script Kotlin de 50 lignes qui tape sur un gRPC-gateway. Mettre en place grpc-kotlin et protoc juste pour ça est démesuré. Génère les data classes ici et mets-les dedans.

Questions courantes

C'est un remplaçant de protoc-gen-kotlin ?

Non. Le vrai codegen produit les méthodes marshal/unmarshal, les descripteurs et les stubs gRPC. Cet outil n'émet que les formes de data class. Lance grpc-kotlin pour du code gRPC de prod. Sers-toi de ça pour des esquisses, du parsing JSON, des revues et des scripts ponctuels.

Pourquoi les champs message singuliers sont nullable ?

En proto3, les champs de type message ont une sémantique "has value" — ils peuvent être non définis. L'équivalent Kotlin le plus propre est une propriété nullable avec default null. Si tu sais que tes données peuplent toujours ces champs, retire le ? et le default — find-replace direct.

Comment sont gérés uint32 et uint64 ?

Les deux mappent vers des types signés (Int et Long). Kotlin a des types UInt et ULong stables depuis 1.5, mais les types signés sont plus compatibles avec les libs de sérialisation existantes et la plupart des codebases Android. Si tu as spécifiquement besoin des variantes non signées, swap dans la sortie.

Comment sont émis les enums ?

Chacun devient une enum class WithValue(val value: Int) pour que tu puisses préserver l'entier du format wire. Chaque valeur prend le nom proto d'origine (par ex. ORDER_STATUS_PENDING) — les entrées d'enum Kotlin sont conventionnellement déjà en SCREAMING_SNAKE_CASE, donc ça colle.

Comment sont convertis les noms de champs ?

snake_case → camelCase selon les conventions de codage Kotlin. order_id devient orderId, customer_name devient customerName. Les noms de classe et d'enum restent en PascalCase comme dans le proto.

Gère-t-il les messages imbriqués ?

Oui — les blocs message imbriqués sont aplatis en déclarations data class de niveau racine dans la sortie. Ça garde le fichier facile à lire et à découper en plusieurs fichiers. Si tu préfères les classes imbriquées Kotlin, enveloppe-les à la main.

Outils associés

Si tu travailles avec Protobuf et Kotlin, ceux-ci vont bien ensemble :

Convertisseur Protobuf vers Kotlin