RoboPOJOGenerator turns a JSON payload into Kotlin or Java data classes

The problem it solves in one step

RoboPOJOGenerator is an IntelliJ IDEA and Android Studio plugin, and its whole purpose is stated in one line: it generates Kotlin and Java data transfer objects from JSON payload, by inserting the payload and selecting the target serialisation framework.

That is a task that looks trivial and is not. Given a JSON document, the generator has to decide which fields become properties, what type each one gets, how a null is represented, and then apply the conventions of the serialisation library you picked. Serialisers disagree about all of these. GSON uses field access and its own annotations, Moshi wants Kotlin data classes with non-null types and codegen or reflection, Jackson has its own set of property annotations, Parcelable needs Android specific members, AutoValue is an abstract class with generated implementations, and Java records and Lombok want a different shape again.

Doing that by hand for a thirty field response is a chore, and doing it wrong is worse than a chore because the mismatch only shows up at runtime, as a null that was not expected or a field that silently stays at its default.

The list of supported targets is given in the plugin's keyword metadata, and it is a long one: JsonToPojo, Json2Pojo, Kotlin, GSON, FastJSON, AutoValue, Jackson, LoganSquare, Moshi, Parcelable, Lombok, Jakarta JSON Binding, Java records and KotlinX. The plugin is written in Kotlin, is MIT licensed, and the copyright is held by Vadim Shchenev with the year given as 2016.

Installing it and running it in the IDE

The installation is a Marketplace click, and the README is explicit that the official plugin repository is the source.

The instructions say to just get it and install from the official plugin repository, or simply find it in Preferences, then Plugins, then Marketplace, then RoboPOJOGenerator. The plugin listing referenced is the one at plugins.jetbrains.com/plugin/8634, and there is a badge in the README for Android Arsenal, which is a separate directory of Android tooling.

Using it is three steps. First, select a target package, then New, then Generate POJO from JSON. Second, put the JSON payload into the window and select the target serialisation framework. Third, see generated files inside the selected package.

The order matters more than it sounds. The package selection comes first because that is what determines where the files land, and picking the serialisation framework comes second because it changes the shape of what is generated. Doing it in the other order means regenerating after the fact.

There is no configuration file, no template to write and no mapping UI for the JSON structure. The plugin infers the schema from the payload and the framework from your selection, which is the main reason it is fast to use and the main reason it cannot handle a payload whose real shape is not visible in one sample.

The CLI and library paths, which matter more than the plugin

The most consequential line in the README is the one that says you can use RoboPOJOGenerator without IntelliJ, as a library dependency or standalone CLI.

The two routes are documented separately. The CLI is described as raw JSON in, generated files out, with its own README at cli/README.md. The library route is for Java and Kotlin callers, described as calling GeneratorFacade directly, with its README at generator/README.md.

That split is the difference between a developer convenience and a build step. A plugin that only runs inside the IDE produces classes that somebody has to remember to regenerate when the API changes, and nothing enforces that. The same generator available as a CLI can be wired into a build, invoked with a checked in payload, and its output committed, so the model classes and the contract they encode move together in version control.

The module layout in the repository supports that reading. There is a core/ directory, a generator/ directory that holds the GeneratorFacade, a cli/ directory, a main/ directory for the IntelliJ plugin itself, plus build.gradle.kts, settings.gradle.kts, a gradlew wrapper and a gradle/ directory. So the plugin, the library and the command line tool are separate modules in one Gradle build, and the plugin is a consumer of the same code rather than the only way in.

The README does not document the exact invocation of the CLI, so the flags and the output layout are things to read in cli/README.md rather than to guess at.

What the generated code has to get right

The reason the framework choice is the important decision, rather than a detail of the plugin, is that the generated classes have to satisfy two different sets of rules at once.

The first set comes from the serialisation library. It has to bind the JSON property names to the fields, handle the difference between a missing key and an explicit null, and deal with a property whose type is a list or an object rather than a scalar. Some frameworks are happy with a mutable field, others require a val with a default, and the generated nullability has to match what the framework will actually pass.

The second set comes from the language and the platform. For Kotlin that means deciding between a data class and something else, and choosing a nullability that does not contradict the JSON. For Android it means Parcelable support, which means implementing an interface and writing a parcel round trip by hand for a class with thirty fields. For AutoValue it means generating an abstract class plus the implementation, since AutoValue works by annotation processing rather than by producing a concrete class. For Java records it means a record with a fixed component list. Lombok brings its own annotation style. Jakarta JSON Binding is its own specification with its own annotations.

Doing that by hand for a large payload is where projects go wrong, and the mismatch is invisible until a value arrives that the type did not allow. A nullable field typed as non-null is the classic case, and it is the kind of bug that a generator that knows the framework's rules cannot introduce.

There is a related consequence worth stating plainly. The generated types are only as good as the sample payload. Every field, every type and every nullability in the output comes from the JSON you pasted, and a field that never appears in the sample simply does not exist in the class.

The limits of inferring a schema from one sample

This is the failure mode to plan for, and it is inherent to the approach rather than a defect in the implementation.

A single JSON document shows you one shape. If the API sometimes returns a field as a string and sometimes as an object, the generator will pick one. If an array element is sometimes a string and sometimes an object, that is not inferable at all. If a field is absent in the sample, the class will not have it, and if it is present as null in the sample but as a value at runtime, the generated type will be wrong in the direction that fails at runtime rather than at compile time.

None of this is the generator's fault, and the fix is on the user: paste a payload that exercises the real shape, or hand-edit the generated class afterwards. But it does mean the plugin produces a starting point rather than a finished contract, and a team that treats the output as final will find the same class of problem it would have found writing the classes by hand, only later.

There is also the regeneration question. Because the output is derived from a payload rather than from a schema document, re-running the generator on an updated payload will overwrite the manual edits, and the generator has no merge step described in the README. In practice that pushes teams towards either committing the payload alongside the classes and regenerating wholesale, or towards the CLI and library routes where the generated files are a build output rather than files a developer owns.

The CHANGELOG lives at the repository root, and the README points at a copy on the master branch, which is a small sign that the plugin's history is tracked in the repository rather than only in the Marketplace release notes.

Where it sits against hand-written models and other generators

The alternatives are worth naming with their actual differences rather than as a list.

The first alternative is writing the classes by hand, or letting a language's data class generation do it. This is what most teams do at first, and it works fine for small payloads. The cost appears with breadth, because every serialisation framework needs different annotations and boilerplate, and with churn, because an API change means touching every affected class by hand.

The second alternative is a code generation plugin that reads a JSON Schema or an OpenAPI document rather than a sample. That approach produces a better result when you have a schema, because the schema describes optionality and types that a single sample cannot. The trade is that it needs a schema document to exist, and many teams do not have one, especially when the API is somebody else's and only documented in prose. RoboPOJOGenerator's approach starts from the thing you actually have, which is a response body.

The third alternative is a runtime approach, where you keep the JSON as a map and read fields out of it, or use a dynamic decoder. That avoids the class entirely and is the right choice for a payload you only read a few fields from, or one whose shape you expect to change. It costs you type safety and compile time checking, and it is not what the plugin is for.

The plugin's own answer to all of this is coverage of frameworks, and that answer is well founded: the tedium it removes is the per-framework boilerplate, not the schema inference. The last push was on 2026-07-12, the repository is not archived, and there are no GitHub releases, so the plugin's version history lives in the Marketplace and in the CHANGELOG file.

Editorial conclusion

RoboPOJOGenerator suits a team that receives JSON from an API it does not control and wants typed data classes rather than maps, since the plugin handles the per-framework annotation and boilerplate differences for GSON, Moshi, Jackson, FastJSON, LoganSquare, AutoValue, Jakarta JSON Binding, Parcelable, Lombok, Java records and KotlinX. It is the wrong tool if you want the generator to be part of your build, because the plugin is the primary interface and the CLI and library paths are described in separate READMEs, and it is the wrong tool for JSON with structure it cannot infer, such as deeply polymorphic payloads. Before adopting it, install it from the JetBrains plugin repository, and try a single payload against the framework you actually use rather than the one in the demo.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. robohorse/RoboPOJOGenerator on GitHub