Practical guide

Generate Java classes and records from JSON

Java model generation is most useful when a JSON response is already real and you need a quick class or record draft for review. JSON All-in-One can generate Java code from a sample and, where selected, include Jackson-oriented annotations.

Generated model code, dependency setup, and deserialization configuration are three different pieces of work. The generator focuses on Java model classes and optional Jackson-oriented annotations; other frameworks and runtime configuration remain yours to add.

Choose a fixture with Java problems in it

This illustrative order response includes snake_case keys, a decimal amount, a nullable discount, a nested customer object, and a status that might become an enum. It is deliberately small, but it exercises the decisions a Java reader cares about.

Use a source with keys that differ from Java naming conventions. That gives the Jackson option something real to explain: the generated field can preserve the JSON key, and any later Java-side renaming must keep the JSON name visible by annotation or mapping code.

Illustrative root-object order JSONjson
{
  "order_id": "ord_1007",
  "status": "paid",
  "total_amount": 129.95,
  "placed_at": "2026-09-04T10:05:00Z",
  "discount": null,
  "customer": {
    "customer_id": 42,
    "email": "buyer@example.dev"
  }
}

Choose record or class deliberately

Java supports Record and Class style in the current option matrix. Records are concise and fit immutable data carriers in modern Java. Classes can be friendlier when a project expects setters, no-argument constructors, or framework-specific conventions.

After generation, look at the downloaded files rather than assuming the layout from the toggle. If Java gives you separate public types, keep them as separate files or merge them manually only after checking Java's one-public-type-per-file rule.

OrderResponse.java (reviewed Jackson record for the root object)java
package dev.example.orders;

import com.fasterxml.jackson.annotation.JsonProperty;
import java.time.OffsetDateTime;

public record OrderResponse(
    @JsonProperty("customer") Customer customer,
    @JsonProperty("discount") Object discount /* nullable */,
    @JsonProperty("order_id") String order_id,
    @JsonProperty("placed_at") OffsetDateTime placed_at,
    @JsonProperty("status") String status,
    @JsonProperty("total_amount") Double total_amount
) {}
Customer.java (separate model file in the same package)java
package dev.example.orders;

import com.fasterxml.jackson.annotation.JsonProperty;

public record Customer(
    @JsonProperty("customer_id") Long customer_id,
    @JsonProperty("email") String email
) {}

Jackson is an option, not the whole integration

When Jackson is selected, generated annotations can preserve source names such as order_id. They do not add Maven or Gradle dependencies, configure Java time support, or choose every ObjectMapper option your service uses.

Add build configuration and mapper setup in your application, separately from the generated model files. This keeps dependency and framework choices aligned with the project that will use the models.

Handwritten Jackson usage to verify separatelyjava
ObjectMapper mapper = new ObjectMapper()
    .findAndRegisterModules();

OrderResponse order = mapper.readValue(jsonText, OrderResponse.class);
System.out.println(order.customer().email());

Review numbers, dates, and unknown values

Java integer policy can use Long or BigInteger; decimal policy can use Double or BigDecimal; date/time can be OffsetDateTime or String; unknown JSON can be Object or String. The right answer depends on the receiving code.

For order totals, consider the BigDecimal path and verify the mapper setup that reads it. Treat fields typed as Object as values your application still needs to inspect and handle explicitly.

DecisionJava choicesReader warning
Model styleRecord or ClassRecord examples imply a modern Java version.
SerializerNone or JacksonNo Gson or arbitrary POJO framework claim.
IntegerLong or BigIntegerCheck identifiers and IDs before native numeric use.
DecimalDouble or BigDecimalMoney examples should not silently use binary float.

Workflow checklist

  1. Open the JSON sample and choose Java in Codegen.
  2. Select record or class style based on the project conventions.
  3. Choose Jackson only if you also include the Jackson-specific output and dependencies.
  4. Set the package name and inspect the actual generated file list.
  5. Compile and, if you use Jackson in your project, deserialize the fixture with recorded Java and dependency versions.

Limitations to state in plain English

Generating Java from JSON is not the same as parsing JSON into an already designed domain model. It drafts model classes from observed input. Business validation, field renaming policies, dependency management, and framework integration remain your code.

Do not infer Gson, Moshi, Spring binding behavior, or arbitrary POJO conventions from the Jackson option. Keep generated model code separate from handwritten mapper setup.

Workflow and integration boundary

Generate Java records from a 300-settlement response, choose explicit date and decimal policies, compile the exact multi-file output, and deserialize the original fixture with Jackson.Watch on YouTube
Diagram showing generated Java models on one side and handwritten application integration code on the other.
Architecture diagram separating generated records and Jackson annotations from handwritten ObjectMapper setup, validation, dependency management, and domain mapping.