JSON to Java: Differences, Edge Cases & Pitfalls

Generate Java POJOs from JSON with a clear split between primitives and wrappers, plus Jackson or Gson annotation notes.

The output is a plain POJO not tied to any JSON library, so snake_case keys will not map themselves — add @JsonProperty or @SerializedName. The primitive-versus-wrapper rule is clear: anything nullable or optional must use the wrapper type.

Format Differences

AspectJSONJava POJO
NamingcamelCase / snake_case mixedcamelCase fields with annotations mapping wire names
NullabilityFields may be absent or nullPrimitives cannot be null; use wrappers
NumbersOne number typeChoose int/long/BigDecimal by hand
Money precisiondouble under the hoodBigDecimal is exact; double is not
ArraysNativeList<T> or T[] generics
NestingNested objectsNested POJOs or Map
ImmutabilityNot applicablerecord (Java 16+) or final fields
Serialisation costLowReflection is heavier; compile-time options are faster

Edge Cases

  • Pick long over int for epoch milliseconds — int overflows into negatives immediately.
  • If a JSON number arrives in scientific notation, some BigDecimal parsers produce different values; configure the precision strategy.
  • An unknown enum value throws by default; production usually needs "ignore unknown" or an UNKNOWN mapping.
  • Cyclic references overflow the stack during serialisation — ignore them or break the cycle with a DTO.

Common Pitfalls

  • A primitive int receiving null throws an NPE or fails parsing outright.
  • Snake_case keys without annotations leave every field null, without an error.
  • Money as double accumulates cent-level drift and reconciliation never balances.
  • Epoch milliseconds in an int overflow into negative numbers.
  • A JSON null hitting a Java primitive throws an NPE; only wrapper types such as Integer or Long accept it, so choose types by nullability when modelling.

Related Tools