# jsonschema2pojo: generating Java types from JSON Schema with Maven, Gradle or the CLI

> jsonschema2pojo turns JSON Schema or sample JSON into annotated Java classes for Jackson or Gson. The build-plugin route is the one that scales; the online generator is the one people try first.

**joelittlejohn/jsonschema2pojo** — Generate Java types from JSON or JSON Schema and annotate those types for data-binding with Jackson, Gson, etc

- Repository: https://github.com/joelittlejohn/jsonschema2pojo
- Website: http://www.jsonschema2pojo.org
- Stars: 6,381 · Forks: 1,673
- Language: Java
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/joelittlejohn-jsonschema2pojo

## What jsonschema2pojo produces, and who is asking for it

The project generates Java types from JSON Schema, or from example JSON, and annotates those types for data binding with Jackson 2.x, Jackson 3.x, or Gson. That sentence is the whole scope. It is a code generator, not a validator and not a runtime library.

The audience is narrow and specific. If you consume a third-party API that publishes a JSON Schema, or if your own service publishes one and a Java client has to be kept in step with it, you are the intended user. Without a generator you either hand-write POJOs and keep them in sync by discipline, or you work with JsonNode and Map<String, Object> and lose type information at every call site. jsonschema2pojo sits between those two options: the schema stays the source of truth, and the Java classes are derived from it.

The annotation target matters more than it first appears. Because the generated classes carry Jackson or Gson annotations, they are usable directly with the binding library you already have, rather than requiring an adapter layer. The README names Jackson 2.x, Jackson 3.x, and Gson as the supported targets, which is a wider spread than most generators of this kind bother to maintain.

## How the schema becomes Java: the generation pipeline

The repository is split into modules that mirror the ways the tool can be invoked: jsonschema2pojo-core holds the generation logic, and jsonschema2pojo-maven-plugin, jsonschema2pojo-gradle-plugin and jsonschema2pojo-cli are the entry points around it. There is also a jsonschema2pojo-jdk-annotation module and an integration test module.

That layout tells you the intended data flow. A caller supplies a source directory of schema files and a target package. The core module reads each schema, maps JSON Schema constructs onto Java types, and writes .java files into the target package. The plugins exist so that this happens during a build rather than as a manual step.

The mapping is where the interesting decisions live, and it is also where the README stops. JSON Schema allows unions, unconstrained objects, and recursive references; Java does not have a direct equivalent for all of them. The Reference wiki page is where those mappings are documented, and it is the page worth reading before you commit to a schema, not after. A schema that is perfectly reasonable as a wire contract can still produce awkward Java if it leans on constructs the generator has to approximate.

## Installing jsonschema2pojo with Maven and running a first generation

The README gives a Maven plugin configuration as its first example. It points sourceDirectory at a schema folder and targetPackage at the package the generated classes should land in, then binds the generate goal. The version shown is 1.3.3, which matches the most recent release in the repository's release list.

```xml
<plugin>
    <groupId>org.jsonschema2pojo</groupId>
    <artifactId>jsonschema2pojo-maven-plugin</artifactId>
    <version>1.3.3</version>
    <configuration>
        <sourceDirectory>${basedir}/src/main/resources/schema</sourceDirectory>
        <targetPackage>com.example.types</targetPackage>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>generate</goal>
            </goals>
        </execution>
    </executions>
</plugin>
```

Two things have to be true before this runs. The directory named in sourceDirectory must exist and contain at least one schema file, and the package named in targetPackage is the one the generated sources will be written into. The README does not state where the generated files are placed on disk; that detail is on the Maven plugin documentation page linked from the README, so check it there rather than assuming src/main/java.

There is also a Gradle route, which the README shows with the org.jsonschema2pojo plugin id at the same version and a jsonSchema2Pojo configuration block:

```groovy
plugins {
  id "java"
  id "org.jsonschema2pojo" version "1.3.3"
}

repositories {
  mavenCentral()
}

jsonSchema2Pojo {
  targetPackage = 'com.example'
}
```

If you would rather not touch the build at all, the README points at a hosted generator at jsonschema2pojo.org and notes that brew install jsonschema2pojo installs a local command line utility. The CLI module in the repository is the same tool packaged for terminal use.

## Where jsonschema2pojo is the wrong tool

The most common mismatch is expecting validation. jsonschema2pojo reads a schema at build time and emits classes. It does not check incoming JSON against that schema at runtime. If a payload arrives with a missing required field or a string where the schema says integer, the generated classes will not catch it; you need a separate validator for that. Teams that adopt the generator expecting schema enforcement discover this late.

The second mismatch is schema style. JSON Schema is expressive in ways Java is not, and the generator has to make choices. A schema that uses broad unions, or that leaves object properties unconstrained, will produce types that are legal Java but not pleasant to use. This is a property of the translation, not a bug, but it means the quality of the generated output is largely a function of how disciplined the schema author was.

The third is workflow. Generated code that is checked into version control invites hand-editing, and hand-edited generated code is lost on the next regeneration. Generated code that is ignored by version control means every developer and every CI job must run the generator before compiling. Neither choice is wrong, but the project does not make it for you, and the README does not discuss the trade-off.

## How it compares with writing the binding by hand or using a runtime mapper

The alternative most teams actually weigh is not another generator. It is hand-written POJOs, or a runtime mapping library that works from annotations you write yourself.

The difference is where the schema lives. With hand-written classes, the schema is documentation and the Java is the truth. When the upstream schema changes, nothing breaks at compile time; you find out when a field comes back null. With jsonschema2pojo, the schema is the input and the Java is derived, so a schema change shows up as a diff in generated code during the build. That is the actual value proposition, and it is worth being clear that it is about change detection, not about saving typing.

The cost is a build step and a dependency on the generator's mapping decisions. Hand-written classes can express things the generator cannot, and they never surprise you with a regeneration diff. If your JSON payloads are small and stable, hand-writing is genuinely less machinery. jsonschema2pojo earns its place when the schema is large, changes independently of your code, or is shared across several consumers.

## Maintenance, releases and the Apache-2.0 licence

The last push to the repository was on 2026-05-02, and the most recent releases listed are 1.3.3 on 2026-02-08, 1.3.2 on 2026-02-02 and 1.3.1 on 2026-02-01. The repository is not archived. The release cadence in early 2026 was three versions inside eight days, which is a burst rather than a steady rhythm, so pin an explicit version in your build rather than tracking a range.

The version you pin appears in three places if you use the plugins: the Maven plugin version, the Gradle plugin version, and whatever annotation library version your classpath carries. Jackson 2.x and Jackson 3.x are different major lines, and the README lists both as supported targets, so the annotation style you select has to match what is actually on the classpath. A mismatch here surfaces as compile errors in generated code, which is at least a loud failure.

The project is licensed under Apache License, Version 2.0. That is a permissive licence, and the practical implication for most teams is that generated output carries no copyleft obligation. This is not legal advice; if your organisation has rules about generated code provenance, check the NOTICE file in the repository alongside the LICENSE.

## Conclusion

Adopt jsonschema2pojo when a JSON Schema or representative JSON payload is already the contract your service publishes, and you want Java classes that track it inside the build. Do not adopt it if you need runtime schema validation, if your schema leans on constructs the generator cannot map to Java, or if you expect the generated sources to be the place where you add behaviour. Before wiring it in, verify three things: that the target package and source directory you configure actually exist in your layout, that the annotation style you pick matches the Jackson or Gson version already on your classpath, and that the generated output committed or ignored by your build is a decision you have made rather than a default. The Maven plugin snippet in the README is the smallest thing you can run to answer all three.

## FAQ

### How do I use the jsonschema2pojo Maven plugin?

Add the jsonschema2pojo-maven-plugin to your pom.xml with a sourceDirectory pointing at your schema folder and a targetPackage for the generated classes, then bind the generate goal in an execution. The README's example uses version 1.3.3.

### How do I use jsonschema2pojo?

You can run it as a Maven plugin, a Gradle plugin, a command line utility, or embedded in your own Java app. The README points at the Getting Started wiki page for the full setup, and also offers an online generator at jsonschema2pojo.org.

### Does jsonschema2pojo support Jackson 3?

Yes. The README states that generated types can be annotated for data binding with Jackson 2.x, Jackson 3.x, or Gson.

### Does jsonschema2pojo validate JSON at runtime?

No. It reads a schema at build time and writes Java source files. Nothing in the README describes runtime validation of incoming payloads against the schema.

### What licence does jsonschema2pojo use?

The repository is licensed under the Apache License, Version 2.0, and the LICENSE and NOTICE files sit at the top level of the repository.

## Sources

- [joelittlejohn/jsonschema2pojo on GitHub](https://github.com/joelittlejohn/jsonschema2pojo)
- [License: Apache-2.0](https://github.com/joelittlejohn/jsonschema2pojo/blob/master/LICENSE)
- [Project website](http://www.jsonschema2pojo.org)
- [README](https://github.com/joelittlejohn/jsonschema2pojo/blob/master/README.md)
- [Releases](https://github.com/joelittlejohn/jsonschema2pojo/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/joelittlejohn-jsonschema2pojo