DEV Community: Yu Han

What makes it more interesting than a basic schema-to-POJO converter is that it exposes modeling decisions directly.

Schema-to-code is not only about mapping types. It is also about deciding what should become part of a stable Java API, and what should remain flexible.

Try it here

👉 Tool: https://sjf4j.org/generator

What the tool does

The generator is a browser-based playground for turning JSON Schema into Java scaffolding.

It currently supports:

package and class name configuration
primitive / number / date-time mapping choices
string enum → Java enum generation
nested object → inner class generation
required-field-aware generation
validation annotations such as @NotNull
JavaDoc generation from schema metadata
allOf flattening for object schemas
local $ref expansion
deterministic import and member ordering

One of the strongest parts of the tool is its customization model:

global configuration for overall generation behavior
property-by-property overrides in the Parsed Properties panel

So the tool does not force one all-or-nothing rule across the whole schema. A project can start with a global baseline, then adjust selected members one by one.

A simple example

Given a schema like this:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Order",
  "description": "Checkout order created by the storefront.",
  "type": "object",
  "required": ["id", "amount", "createdAt", "customer", "items"],
  "properties": {
    "id": {
      "type": "string",
      "description": "Business order identifier."
    },
    "amount": {
      "type": "number",
      "description": "Total amount in the settlement currency."
    },
    "createdAt": {
      "type": "string",
      "format": "date-time"
    },
    "paid": {
      "type": "boolean"
    },
    "customer": {
      "type": "object",
      "required": ["id", "email"],
      "properties": {
        "id": {
          "type": "string"
        },
        "email": {
          "type": "string"
        }
      }
    },
    "items": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["sku", "quantity"],
        "properties": {
          "sku": {
            "type": "string"
          },
          "quantity": {
            "type": "integer"
          }
        }
      }
    }
  }
}

With the default JOJO-oriented settings, the generated Java can look like this:

@Getter @Setter
public class Order extends JsonObject {
    /**
     * JSON shape:
     * <pre>
     * {
     *   "id": "string",
     *   "amount": "number",
     *   "createdAt": "string(date-time)",
     *   "paid": "boolean",
     *   "customer": {
     *     "id": "string",
     *     "email": "string"
     *   },
     *   "items": [
     *     {
     *       "sku": "string",
     *       "quantity": "integer"
     *     }
     *   ]
     * }
     * </pre>
     */
    @NotNull private String id;
    @NotNull private double amount;
    @NotNull private OffsetDateTime createdAt;
    private boolean paid;
    @NotNull private Customer customer;
    @NotNull private List<ItemsItem> items;

    private static final JsonPath PATH_CUSTOMER_EMAIL = JsonPath.compile("$.customer.email");

    public String getCustomerEmail() {
        return PATH_CUSTOMER_EMAIL.getString(this);
    }

    public String getItemsSku(int itemsIndex) {
        return getStringByPath("$.items[" + itemsIndex + "].sku");
    }

    @Getter @Setter
    public static class Customer extends JsonObject {
        @NotNull private String id;
        @NotNull private String email;
    }

    @Getter @Setter
    public static class ItemsItem extends JsonObject {
        @NotNull private String sku;
        @NotNull private int quantity;
    }
}

This is closer to a real API shape: nested objects, arrays, required members, generated inner classes, validation annotations, and root-level path accessors.

Why modeling choices matter

The generator is not designed as a “turn every JSON property into a field” machine.

In real systems, the harder question is usually:

Which parts of this schema should become a stable Java contract, and which parts should stay flexible?

That is why the tool exposes decisions such as:

JOJO vs POJO modeling
field vs property generation
path accessor generation on the root model
per-property type overrides
global defaults plus property-by-property adjustments

This matters when the input schema comes from:

a third-party API that changes often
an event payload with optional extension fields
an internal contract that is stable in some places and fluid in others

Why JOJO is interesting here

This generator is part of the broader SJF4J ecosystem, so it can generate models that fit naturally into SJF4J’s structural APIs.

If an object is modeled as a JOJO, it extends org.sjf4j.JsonObject.

That gives you an interesting hybrid:

typed Java members where you want a stable contract
dynamic JSON-style access where you still need flexibility

For example, the generator can produce root-level descendant accessors such as:

public String getCustomerEmail() {
    return PATH_CUSTOMER_EMAIL.getString(this);
}

public String getItemsSku(int itemsIndex) {
    return getStringByPath("$.items[" + itemsIndex + "].sku");
}

That is a different direction from classic schema-to-POJO generators. It is useful when the generated model is not just a DTO, but part of a larger JSON-processing workflow.

Global configuration and per-property tuning

Customization happens at two levels.

At the global level, the generator can define the overall baseline for a file:

package and class name
JOJO or POJO preference
field-generation strategy
accessor strategy
path-accessor strategy
integer / number / boolean / enum / date-time mapping
object-leaf mapping
validation namespace and annotations
JavaDoc generation

At the property level, the Parsed Properties panel can refine specific members:

switch between field and property generation
override the generated Java type
enable or disable by-path getter/setter generation for eligible paths

That makes the tool flexible enough for mixed schemas, where most properties follow one rule but a few important members need a different Java contract.

Where this fits in SJF4J

If you have not seen SJF4J before, it is a unified JSON-semantic processing layer for Java.

It provides one structural model across:

parsing
modeling
JSON Path navigation
JSON Patch / Merge Patch
JSON Schema validation
mapping / transformation

In practice, that means you can:

start from a JSON Schema
generate a Java model
parse payloads into that model
navigate it with JSON Path
validate it with JSON Schema
keep dynamic structure where needed

That end-to-end flow is why this generator fits naturally on the SJF4J site instead of being treated as an isolated utility.

A few implementation details worth keeping explicit

Some current baseline behaviors:

nested object schemas generate as public static inner classes
nested enums are generated inside the owning class
imports are deduplicated and sorted
object allOf is flattened before rendering
circular local $ref chains are rejected
unsupported non-local $ref is ignored for now
root path accessors are generated only when the root model is a JOJO

In other words, the tool tries to be predictable first, and flexible second — but without hiding the rules.

Another useful detail: the full generation rules are published on the page itself. So the tool is not a black box. The page also works as a spec-like baseline and regression target: the rules are explicit enough to be reused as an AI prompt, allowing an LLM to reproduce a similar generator — or help design a more optimized one on top of the same contract.

Why this is useful

The practical value is simple: the first draft of a Java model should be fast to get, but not locked into the wrong abstraction too early.

If you only need quick scaffolding, the generator already helps.

If you care about long-term maintainability, the more useful part is that it makes the trade-offs visible:

strict vs flexible object modeling
field-backed vs dynamic property-backed members
plain DTO generation vs JSON-semantic access patterns

Try it and tell me what is missing

If you want to try it:

Generator: https://sjf4j.org/generator
SJF4J docs: https://sjf4j.org/docs/getting_started
GitHub: https://github.com/sjf4j-projects/sjf4j

If you are already working with JSON Schema, Java DTO generation, or mixed typed/dynamic payloads, useful feedback would include:

nullable handling
multi-file output layout
more $ref composition cases
better defaults for boxed vs primitive types

Schema-to-code is easy to automate.

Designing good Java boundaries is still the hard part.

SJF4J 1.2.0: Jackson 3 Support, Instance-Based Runtime, and More Predictable JSON Semantics

Yu Han — Sun, 12 Apr 2026 00:13:48 +0000

Java already has excellent JSON libraries. So why build another layer on top?

Because in real applications, JSON work is rarely just "parse this string into a POJO". It quickly expands into:

navigating nested structures
applying JSON Patch or Merge Patch
validating with JSON Schema
mapping between object graphs
keeping behavior consistent across Jackson, Gson, Fastjson2, JSON-P, YAML, and in-memory nodes

That is the problem space SJF4J is trying to solve.

SJF4J is a lightweight structural processing framework for Java that provides a unified JSON-semantic layer across different backends and data shapes. It works with regular POJOs, dynamic JSON-like structures, JSON Path, JSON Patch, JSON Schema, and multiple runtime backends, while keeping the programming model consistent.

Version 1.2.0 is an important release. It adds Jackson 3 support, introduces a cleaner instance-based runtime API, and tightens semantic consistency in several areas that matter in production systems.

What SJF4J Is

SJF4J is not trying to replace Jackson or Gson.

Instead, it sits one level above them and gives you a consistent structural API for:

modeling object-based node trees
parsing JSON and YAML
navigating with JSON Path and JSON Pointer
patching with JSON Patch and Merge Patch
validating with JSON Schema Draft 2020-12
mapping across native object graphs

It also supports runtime backend auto-detection, so the same SJF4J-facing code can work across multiple JSON libraries.

What’s New in 1.2.0

1. Jackson 3 support

SJF4J 1.2.0 adds Jackson 3 facade integration.

At runtime, SJF4J can automatically select an available backend in this priority order:

Jackson 3
Jackson 2
Gson
Fastjson2
JSON-P
built-in simple fallback

2. `Sjf4j` is now instance-based

This is the biggest API change in 1.2.0.

Sjf4j.global() for shared process-wide defaults
new Sjf4j() for a fresh default instance
Sjf4j.builder() for explicit runtime configuration

Migration example

Before:

User user = Sjf4j.fromJson(json, User.class);

After:

User user = Sjf4j.global().fromJson(json, User.class);

If you want an isolated runtime instead of global defaults:

Sjf4j sjf4j = Sjf4j.builder()
    .jsonFacade(new Jackson3JsonFacade())
    .build();

User user = sjf4j.fromJson(json, User.class);

This change makes runtime configuration more explicit and easier to reason about, especially in applications that care about isolation, testing, or framework integration.

3. `@NodeBinding` makes POJO binding rules explicit

Another important addition in 1.2.0 is @NodeBinding.

It moves binding behavior like naming strategy and access policy onto the type itself, instead of relying on mutable global behavior.

For example:

@NodeBinding(naming = NamingStrategy.SNAKE_CASE)
class UserProfile {
    public String userName;
    public int loginCount;
}

Now JSON like this:

{
  "user_name": "han",
  "login_count": 7
}

can map cleanly without per-field annotations.

You can also control access strategy:

@NodeBinding(access = AccessStrategy.FIELD_BASED)
class PrivateUserProfile {
    String userName;
    int loginCount;
}

This is a good example of SJF4J’s overall direction in 1.2.0: make semantics more explicit, cacheable, and predictable.

4. Better consistency for containers and object graph conversion

SJF4J 1.2.0 improves how it handles concrete container types such as:

Map
List
Set

In previous edge cases, framework-level conversion could fall back to generic mutable containers even when more specific target container information was available. In 1.2.0, container metadata and factory paths are improved so declared concrete container implementations are preserved more consistently when supported.

This matters when your application logic depends on more than just the abstract interface type.

5. More correct behavior in Path, Patch, and Schema

This release also includes a long list of semantic fixes across some of the hardest parts of structured data processing.

JSON Schema Draft 2020-12

SJF4J already supports JSON Schema Draft 2020-12, and 1.2.0 improves several edge cases in compilation and validation, including:

unknown keywords and formats
relative $ref resolution
local schemas without root $id
null subschema handling
Unicode code point length for strings
stricter format checks for hostname, IPv6, URI template, and relative JSON Pointer

For teams using schema validation in production APIs, these details are much more important than flashy surface-level features.

Quick Start

If you want to try it:

Gradle

implementation("org.sjf4j:sjf4j:1.2.0")

Maven

<dependency>
  <groupId>org.sjf4j</groupId>
  <artifactId>sjf4j</artifactId>
  <version>1.2.0</version>
</dependency>

Then start with the global runtime:

Sjf4j sjf4j = Sjf4j.global();
User user = sjf4j.fromJson(json, User.class);

Final Thoughts

SJF4J 1.2.0 feels like a solid step forward for Java developers who want a single structural programming model across different JSON backends and data-processing tasks.

If your application only needs plain Jackson databinding, you probably do not need another abstraction layer.

But if your system combines parsing, path navigation, patching, schema validation, dynamic fields, and backend flexibility, SJF4J is solving a real problem, and 1.2.0 makes that solution cleaner and more production-friendly.

Project links:

GitHub: https://github.com/sjf4j-projects/sjf4j
Docs: https://sjf4j.org

We benchmarked JSONPath in Java. Result: up to 7x faster — without changing your data model.

Yu Han — Sun, 29 Mar 2026 02:42:55 +0000

Yu Han

Mar 29

SJF4J vs Jayway JsonPath: Up to 7x Faster in Java Benchmarks

#java #json #performance #opensource

Comments

3 min read

SJF4J vs Jayway JsonPath: Up to 7x Faster in Java Benchmarks

Yu Han — Sun, 29 Mar 2026 02:41:24 +0000

We benchmarked JSONPath in Java.

SJF4J: https://github.com/sjf4j-projects/sjf4j

Jayway JsonPath: https://github.com/json-path/JsonPath

Result:

SJF4J is up to 7x faster.

Here’s what we found.

Benchmark Setup

We built a JMH benchmark suite comparing:

SJF4J v1.5.0
Jayway JsonPath v2.9.0

Across three workload shapes:

Path compilation
Query on shared JsonNode
Query on Map/List object graphs

JMH config:

5 × 300ms warmup
8 × 300ms measurement
2 forks
1 thread

Expressions used:

$.store.book[1].price
$.store.bicycle.color
$.store.book[*].author
$..price
$.store.book[?(@.price > 10)].title
$.store.book[0,2].title

Headline Results

Geometric mean (lower is better):

Benchmark group	SJF4J	Jayway	Result
compile	97 ns/op	125 ns/op	SJF4J 1.28x faster
query_definite	100 ns/op	237 ns/op	SJF4J 2.38x faster
query_indefinite	656 ns/op	1294 ns/op	SJF4J 1.97x faster
query_map_list_definite	31 ns/op	200 ns/op	SJF4J 6.38x faster
query_map_list_indefinite	280 ns/op	1301 ns/op	SJF4J 4.65x faster

TL;DR

~2x faster on typical queries
up to 7x faster on Map/List
faster compilation as well

1) Query on Shared JsonNode

This is the fairest comparison: both libraries query the same parsed tree.

Definite paths

Expression	SJF4J	Jayway	Result
`$.store.book[1].price`	111 ns/op	260 ns/op	2.35x faster
`$.store.bicycle.color`	90 ns/op	216 ns/op	2.40x faster

Indefinite paths

Expression	SJF4J	Jayway	Result
`$.store.book[*].author`	342 ns/op	910 ns/op	2.66x faster
`$..price`	1736 ns/op	3877 ns/op	2.23x faster
`$.store.book[?(@.price > 10)].title`	1292 ns/op	1660 ns/op	1.29x faster
`$.store.book[0,2].title`	242 ns/op	478 ns/op	1.98x faster

Conclusion:

SJF4J is consistently faster as a JSONPath engine.

🚀 2) Query on Map/List Object Graphs

This is where the gap becomes much larger.

Both libraries support Map/List style object graphs, so this is still a fair comparison.

Definite paths

Expression	SJF4J	Jayway	Result
`$.store.book[1].price`	37 ns/op	280 ns/op	7.50x faster
`$.store.bicycle.color`	26 ns/op	142 ns/op	5.42x faster

Indefinite paths

Expression	SJF4J	Jayway	Result
`$.store.book[*].author`	135 ns/op	1045 ns/op	7.73x faster
`$..price`	543 ns/op	2495 ns/op	4.59x faster
`$.store.book[?(@.price > 10)].title`	823 ns/op	1836 ns/op	2.23x faster
`$.store.book[0,2].title`	102 ns/op	598 ns/op	5.89x faster

Takeaway:

If your application already works on Map/List object graphs,

this is the strongest result in the entire benchmark.

🔥 3) Native Object Graphs: POJO / JOJO

This is where SJF4J goes beyond traditional JSONPath libraries.

Instead of forcing everything into a JSON AST, SJF4J runs directly on:

Map / List
JOJO (JSON Object + Java Object hybrid)
POJO

Jayway does not support this model natively.

So here we compare SJF4J across different object representations.

Geometric mean

Benchmark group	Map/List	JOJO	POJO
definite	31 ns/op	43 ns/op	94 ns/op
indefinite	270 ns/op	373 ns/op	554 ns/op

Representative results

Expression	Map/List	JOJO	POJO
`$.store.book[1].price`	37 ns/op	46 ns/op	102 ns/op
`$.store.bicycle.color`	26 ns/op	40 ns/op	87 ns/op
`$.store.book[*].author`	131 ns/op	196 ns/op	374 ns/op
`$..price`	496 ns/op	914 ns/op	955 ns/op
`$.store.book[?(@.price > 10)].title`	807 ns/op	876 ns/op	1100 ns/op

What this shows:

Map/List is fastest (no abstraction)
JOJO adds minimal overhead
POJO is slower, but still practical

The key insight:

You can run JSONPath directly on your domain model.

No conversion. No intermediate tree.

What This Means in Practice

Instead of:

POJO → JsonNode → JSONPath → result

You can do:

POJO → JSONPath → result

This removes an entire layer from your data processing pipeline.

Why Is SJF4J Faster?

The performance difference mainly comes from:

no forced conversion into a dedicated AST
direct execution on native Java object graphs
lower abstraction overhead in path evaluation

In short:

SJF4J avoids work that other libraries must do first.

Bottom Line

Jayway is fine for basic JSONPath usage.

But if performance matters, especially on Map/List or POJO object graphs:

SJF4J is simply faster.

Links

GitHub: https://github.com/sjf4j-projects/sjf4j

Benchmark source: JsonPathCompareBenchmark.java

SJF4J: A Structured JSON Facade for Java

Yu Han — Mon, 23 Mar 2026 11:17:34 +0000

Introduction

Working with JSON in Java usually means choosing between two approaches:

Data binding (POJO) — strong typing, but rigid
Tree model (JsonNode / Map) — flexible, but unstructured

Most libraries force you to pick one and live with the trade-offs.

SJF4J (Simple JSON Facade for Java) takes a different approach:
it introduces a unified JSON-semantic layer that supports both structured and dynamic access — without locking you into a single model.

What SJF4J Is

SJF4J is not a JSON parser.
It is a facade layer built on top of existing parsers (e.g., Jackson), providing:

Unified node model
Structured + dynamic access
Schema-aware capabilities
JSON-semantic operations

The goal is to make JSON handling more consistent, expressive, and extensible.

Core Idea: Unified Node Semantics

In SJF4J, all JSON values are treated as nodes with consistent behavior.

You can operate on them via:

Object-oriented APIs (JsonObject, JsonArray)
Static utilities (Nodes)

Two access styles are supported:

toXxx() → type-safe access
asXxx() → semantic conversion

This removes the need to constantly switch between parsing styles.

Structured + Dynamic in One Model

A key feature is that SJF4J does not force a strict boundary between POJO and dynamic JSON.

You can define structured fields while still allowing flexible extensions.

Example

public class Student extends JsonObject {
    private String name;
    private Map<String, Integer> scores;
    private List<Student> friends;
}

This is neither a traditional POJO nor a raw JSON tree — it’s a hybrid model.

SJF4J calls this pattern JOJO (JSON Object Java Object).

Path and Patch Support

SJF4J includes built-in support for:

JSON Path-like navigation
Patch-style updates

This allows you to manipulate deeply nested structures without manual traversal.

student.putByPath("$.profile.name", "Alice");

Schema Integration

SJF4J integrates JSON Schema as a runtime concept:

Validate data dynamically
Support conditional rules
Separate domain invariants from runtime constraints

This complements traditional validation approaches like Jakarta Bean Validation.

Why Not Just Use Jackson or Gson?

Jackson and Gson are excellent libraries, but they focus on:

Serialization / deserialization
Data binding

SJF4J focuses on a different layer:

JSON as a structured data model
Cross-cutting operations (path, patch, schema)
Hybrid static + dynamic access

It does not replace existing libraries — it builds on top of them.

Performance Considerations

SJF4J operates on top of existing parsers, so performance depends on the underlying implementation.

In typical scenarios:

Overhead is modest
In some cases (e.g., JOJO + optimized IO), performance can be comparable or even slightly better

The design goal is capability without significant cost.

When It Makes Sense

SJF4J is useful when:

JSON structure is partially dynamic
You need both typed access and flexible fields
You work with evolving schemas
You want a unified model for JSON operations

It may be less necessary if:

Your schema is completely static
You only need simple serialization/deserialization

Conclusion

SJF4J explores a different layer in the JSON stack:

Not parsing, not binding — but structuring.

It provides a way to treat JSON as a first-class data model in Java, combining:

Structure
Flexibility
Semantic operations

Project: https://github.com/sjf4j-projects/sjf4j

[Boost]

Yu Han — Thu, 05 Mar 2026 00:42:41 +0000

JSON Patch in Java — Without Converting Everything to JsonNode

Yu Han ・ Mar 4

#java #json

JSON Patch in Java — Without Converting Everything to JsonNode

Yu Han — Wed, 04 Mar 2026 11:26:02 +0000

Partial updates are everywhere.

Modern APIs frequently support HTTP PATCH, and JSON Patch (defined in RFC 6902) has become a standard way to describe structural changes to JSON documents.

A typical patch looks like this:

[
  { "op": "replace", "path": "/name", "value": "Alice Zhang" },
  { "op": "add", "path": "/scores/physics", "value": 91 }
]

Conceptually, it’s simple:

replace a value
add a value
remove something
move something

JSON Patch is elegant.

But when using it in Java, things often become… slightly less elegant.

The Usual Java Workflow

Most JSON Patch libraries operate on JSON tree models.

Which means your code typically looks like this:

POJO
 ↓
JsonNode
 ↓
apply patch
 ↓
JsonNode
 ↓
POJO

In practice this means:

converting your objects into JSON trees
applying the patch
converting everything back

This works, but it introduces extra layers and conversions that aren't really related to the domain model.

A Different Approach

Instead of operating on a JSON tree, SJF4J applies patch operations directly to the object graph.

The workflow becomes:

Object Graph
    ↓
apply patch
    ↓
Object Graph

No intermediate JSON tree.

This works because SJF4J uses a unified structural model called OBNT (Object-Based Node Tree), where native Java objects themselves act as the JSON structure.

Example Model

Let’s start with a simple model:

public class Student extends JsonObject {
    private String name;
    private Map<String, Integer> scores;
    private List<Student> friends;
    // Getters and setters
}

This class extends JsonObject, which means it behaves both as:

a typed Java object
a dynamic JSON structure

Parsing JSON

String json = """
{
  "name": "Alice",
  "scores": {
    "math": 59
  }
}
""";

Student student = Sjf4j.global().fromJson(json, Student.class);

Now student behaves like a normal Java object:

student.getName();

But it also supports JSON-semantic APIs:

student.getInteger("age");
student.getIntegerByPath("$.scores.math");

Defining a JSON Patch

JsonPatch patch = JsonPatch.fromJson("""
[
  { "op": "replace", "path": "/name", "value": "Alice Zhang" },
  { "op": "add", "path": "/scores/physics", "value": 91 }
]
""");

Applying the Patch

patch.apply(student);

After applying the patch:

student.getName(); // Alice Zhang

student.getIntegerByPath("$.scores.physics"); // 91

The object graph is updated in place.

Nested Updates Work Naturally

JSON Patch paths work naturally with nested structures.

Example:

[
  { "op": "add", "path": "/friends/0/scores/music", "value": 100 }
]

Applying this patch will automatically update nested objects.

Comparing Approaches

When patches operate directly on object graphs:

fewer conversions happen
less intermediate structure is required
the code stays closer to the domain model
higher performance

Why JSON Patch Fits This Model

JSON Patch is fundamentally a structural transformation language.

It describes changes in terms of:

paths
operations
values

That makes it a natural fit for a structural object model rather than a serialization layer.

Final Thoughts

JSON Patch is a powerful standard for partial updates.

But the developer experience depends heavily on how it's implemented.

When patch operations work directly on Java object graphs instead of JSON trees, they become significantly simpler to use.

Project:

https://github.com/sjf4j-projects/sjf4j
https://sjf4j.org

2x Faster JSON Schema Validation in Java (Without JsonNode)

Yu Han — Wed, 25 Feb 2026 08:53:06 +0000

Most JSON Schema libraries in Java follow the same pattern:

Validate a JSON string
Or validate a JsonNode
Or validate some library-specific tree model

Which makes sense — JSON Schema was designed for JSON documents.

But in real applications, we rarely live in JSON strings.
We live in Java objects.

So the usual flow looks like this:

POJO → serialize → JsonNode → validate

It works. It’s common.
But it’s not the only possible model.

A Slightly Different Mental Model

Instead of saying:

“JSON Schema validates JSON.”

We can say:

“JSON Schema validates structured data.”

That includes:

POJOs / JOJOs
Map / List
primitive values
any Java objects.

SJF4J treats these as first-class schema nodes via an Object-Based Node Tree model.
There is no mandatory JsonNode layer in between.

So this:

class Order {
    public int id;
    public String user;
}

Can be validated directly:

JsonSchema schema = JsonSchema.fromJson("""
{
  "type": "object",
  "required": ["id"],
  "properties": {
    "id": { "type": "integer" },
    "user": { "format": "email" }
  }
}
""");

schema.compile();

Order order = new Order();
order.id = 1;
order.user = "alice@example.com";

boolean valid = schema.isValid(order);

No serialization.
No JsonNode.
No adapter layer.

Just validate the object.

JSON Schema + JSR 380: Not Competitors

JSR 380 (Bean Validation) is excellent for core invariants:

class User {
    @NotNull
    @Email
    String email;
}

But it’s:

Annotation-driven
Static
Bound to compiled code

JSON Schema handles a different layer:

Runtime-configurable validation
Conditional logic (if/then/else)
Structural policies
Externalized contracts

With SJF4J, you can layer JSON Schema directly onto your domain model:

@ValidJsonSchema("""
{
  "type": "object",
  "required": ["id"],
  "properties": {
    "id": { "type": "integer" },
    "user": { "format": "email" }
  }
}
""")
public class Order {
    public int id;
    public String user;
}

And validate it without converting anything:

SchemaValidator validator = new SchemaValidator();
ValidationResult result = validator.validate(new Order());

In practice, the split becomes very clean:

JSR 380 → domain invariants
JSON Schema → runtime contracts & policies

They complement each other instead of overlapping.

Performance

In local bowtie runs against the official JSON Schema test suite:

SJF4J performs roughly 2× faster than networknt’s validator
Currently among the fastest Java JSON Schema validators in bowtie benchmarks

By validating native objects directly, SJF4J avoids:

Serialization
Re-parsing
Intermediate tree construction

The simpler model isn’t slower.
In many cases, it’s measurably faster.

A Small Architectural Shift

Most JSON tooling in Java assumes:

JSON is primary. Objects are derived.

This flips that:

Structured data is primary. JSON is just a representation.

Once validation operates directly on native objects, a surprising amount of glue code disappears.

Not dramatically.
Not heroically.
Just quietly.

And after writing more adapter layers than I care to admit, I’ve learned to appreciate quiet improvements.

If you’re curious:

https://github.com/sjf4j-projects/sjf4j

SJF4J in 5 Minutes: A Practical JSON Facade for Java

Yu Han — Tue, 06 Jan 2026 11:51:02 +0000

JSON handling in Java is rarely simple.

In real-world applications, data constantly moves between:

POJOs
Map / List
JSON strings
configuration files
APIs with evolving schemas

Java developers are often forced into a painful decision:

Either type safety, or flexibility — but not both.

SJF4J (Simple JSON Facade for Java) is built to remove that trade-off.

What Is SJF4J?

SJF4J is a lightweight facade over popular JSON libraries (Jackson, Gson, Fastjson2) and related formats (YAML, Properties).

It provides a unified semantic layer for structured data processing, fully grounded in JSON specifications.

It does not replace your JSON parser — it unifies how you work with structured data above them.

The Core Idea: Object-Based Node Tree

Instead of introducing a custom JSON AST, SJF4J treats existing Java objects as JSON nodes.

This is called the Object-Based Node Tree (OBNT).

In OBNT:

JSON objects → JsonObject, Map, POJOs
JSON arrays → JsonArray, List, arrays
JSON values → native Java types

Everything stays plain Java — with JSON semantics layered on top.

Quick Example

JsonObject jo = JsonObject.fromJson("""
{
  "id": 1,
  "active": true
}
""");

int id = jo.getInt("id");              // type-safe
String active = jo.getAsString("active"); // Boolean → String

SJF4J offers three access levels:

getXxx → type-safe access
getAsXxx → semantic, cross-type conversion

You choose strictness per call.

Path-Based Access (RFC-Compliant)

SJF4J fully supports:

JSON Path (RFC 9535)
JSON Pointer (RFC 6901)

String name = jo.getByPath("$.user.name");
List<Integer> ids = jo.findByPath("$.items[*].id", Integer.class);

The same path API works across:

JSON
Maps / Lists
POJOs
Hybrid object graphs

Dynamic + Typed: JOJO

SJF4J introduces JOJO (JSON Object Java Object) —
a domain object that extends JsonObject.

class User extends JsonObject {
    String name;
}

user.getName();               // typed
user.getString("age");        // dynamic
user.findByPath("$..name");   // JSON semantics

You can start dynamic and gradually add structure — without breaking APIs.

Declarative Transformation with JsonPatch

SJF4J supports:

JSON Patch (RFC 6902)
JSON Merge Patch (RFC 7386)

JsonPatch patch = JsonPatch.diff(source, target);
patch.apply(source);

Patches work uniformly across POJOs, Maps, Lists, and JSON objects.

When Does SJF4J Shine?

SJF4J is ideal if you:

Work with evolving or semi-structured data
Need both flexibility and type safety
Want one API across multiple JSON libraries
Care about JSON specifications

Summary

SJF4J makes JSON-oriented Java development possible — without early lock-in or excessive boilerplate.

It is small, composable, and specification-driven.

👉 GitHub: https://github.com/sjf4j-projects/sjf4j

DEV Community: Yu Han

A new jsonschema2jojo online tool!

Generating Java from JSON Schema

[Boost]

Generating Java from JSON Schema

Generating Java from JSON Schema

Try it here

What the tool does

A simple example

Why modeling choices matter

Why JOJO is interesting here

Global configuration and per-property tuning

Where this fits in SJF4J

A few implementation details worth keeping explicit

Why this is useful

Try it and tell me what is missing

SJF4J 1.2.0: Jackson 3 Support, Instance-Based Runtime, and More Predictable JSON Semantics

What SJF4J Is

What’s New in 1.2.0

1. Jackson 3 support

2. Sjf4j is now instance-based

Migration example

3. @NodeBinding makes POJO binding rules explicit

4. Better consistency for containers and object graph conversion

5. More correct behavior in Path, Patch, and Schema

JSON Schema Draft 2020-12

Quick Start

Gradle

Maven

Final Thoughts

We benchmarked JSONPath in Java. Result: up to **7x faster** — without changing your data model.

SJF4J vs Jayway JsonPath: Up to 7x Faster in Java Benchmarks

SJF4J vs Jayway JsonPath: Up to 7x Faster in Java Benchmarks

Benchmark Setup

Headline Results

1) Query on Shared JsonNode

Definite paths

Indefinite paths

🚀 2) Query on Map/List Object Graphs

Definite paths

Indefinite paths

🔥 3) Native Object Graphs: POJO / JOJO

Geometric mean

Representative results

What This Means in Practice

Why Is SJF4J Faster?

Bottom Line

Links

SJF4J: A Structured JSON Facade for Java

Introduction

What SJF4J Is

Core Idea: Unified Node Semantics

Structured + Dynamic in One Model

Example

Path and Patch Support

Schema Integration

Why Not Just Use Jackson or Gson?

Performance Considerations

When It Makes Sense

Conclusion

[Boost]

JSON Patch in Java — Without Converting Everything to JsonNode

Yu Han ・ Mar 4

JSON Patch in Java — Without Converting Everything to JsonNode

The Usual Java Workflow

A Different Approach

Example Model

Parsing JSON

Defining a JSON Patch

Nested Updates Work Naturally

Comparing Approaches

Why JSON Patch Fits This Model

Final Thoughts

2x Faster JSON Schema Validation in Java (Without JsonNode)

A Slightly Different Mental Model

JSON Schema + JSR 380: Not Competitors

Performance

A Small Architectural Shift

SJF4J in 5 Minutes: A Practical JSON Facade for Java

What Is SJF4J?

2. `Sjf4j` is now instance-based

3. `@NodeBinding` makes POJO binding rules explicit

We benchmarked JSONPath in Java. Result: up to 7x faster — without changing your data model.