Forem: Yu Han

SJF4J makes Java JSON Schema validation fast not just by validating quickly, but by avoiding the extra JSON-tree step entirely.

Yu Han — Wed, 13 May 2026 08:40:39 +0000

Yu Han

May 13

Is SJF4J the fastest JSON Schema validator for Java?

#java #jsonschema #opensource #performance

Comments

4 min read

Is SJF4J the fastest JSON Schema validator for Java?

Yu Han — Wed, 13 May 2026 08:38:55 +0000

If you benchmark JSON Schema validators in Java, one question matters more than it first appears:

does the validator work directly on your Java object graph, or does it first force you through a JSON tree?

SJF4J is built around the first path.

That is why the recent independent benchmark work from Creek Service is interesting.

Because SJF4J's story is not just "we are fast".

It is: we avoid work that many Java validation pipelines still force you to do.

An independent signal worth paying attention to

Creek Service maintains an independent comparison of JVM JSON Schema validators:

What makes this benchmark especially useful is that it looks at validation from two angles:

pure validation against the JSON Schema test suite
serde-style workflows, where data is serialized, validated, read back, validated again, and deserialized

The first tells you whether a validator is strong at validation itself.
The second tells you how it behaves in something much closer to a real application pipeline.

Why this is good news for SJF4J

Creek Service's results reinforce two things SJF4J has been designed around from the start.

1) SJF4J is fast at pure validation

First: SJF4J is simply strong at pure validation.

That matters because the baseline job of a validator is still the same:

if you already have the schema and already have the data, validation should be fast and boring.

That alone already puts it in very serious company.

2) SJF4J gets more interesting as the workflow gets more real

This is the part that makes SJF4J more than just another validator with a benchmark chart.

Most validators are still easiest to understand as JSON validators.

SJF4J is better understood as a structural data processor for Java object graphs that also includes JSON Schema validation.

Instead, it can validate directly over:

Map / List
POJO
JOJO
other OBNT-compatible object graphs

So when your application is already working with Java objects, SJF4J does not need an extra parse/build pass just to begin validation.

In other words:

less conversion, less representation switching, less wasted work.

And that is exactly the kind of advantage that shows up in serde-style benchmarks.

Why this matters beyond benchmark screenshots

Because the real question is not just:

who wins a benchmark?

It is also:

who forces the least unnecessary work into my application?

In many Java systems, validation is not an isolated toy benchmark. It sits inside a larger flow:

HTTP request handling
event ingestion
Kafka or queue consumers
persistence pipelines
DTO ↔ domain transformations
configuration or document processing

If your validation layer keeps forcing this shape:

POJO -> JSON/tree -> validation -> POJO/domain

then the validator is only part of the cost story.

SJF4J reduces that friction by keeping validation inside the same structural processing model used for:

parsing
navigating
patching
mapping
validating

That gives you a simpler developer model and, very often, a faster runtime path.

A quick example

With SJF4J, schema validation can sit directly on top of a Java model:

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

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

Or you can compile a reusable schema plan explicitly and validate native Java data directly:

JsonSchema schema = JsonSchema.fromJson("""
{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer", "minimum": 0 }
  },
  "required": ["name"]
}
""");

SchemaPlan plan = schema.createPlan();

Map<String, Object> data = Map.of(
    "name", "Ada",
    "age", 18
);

boolean ok = plan.isValid(data);

The key point is not just the API.

The key point is this:

validation happens over the object graph you already have.

SJF4J is not just a validator benchmark story

Another reason this matters: SJF4J is not a one-feature library.

It provides one structural model and one API family across:

JSON / YAML / Properties parsing
JSON Path navigation
JSON Patch / Merge Patch processing
JSON Schema validation
object graph mapping

So if your application needs more than "just validate a schema", SJF4J can simplify more of the pipeline instead of becoming one more isolated dependency with one narrow responsibility.

Where to look next

If you want to explore SJF4J further:

GitHub: sjf4j-projects/sjf4j
Docs: https://sjf4j.org
Validation guide: https://sjf4j.org/docs/validating
Benchmarks: https://sjf4j.org/docs/benchmarks

And if you want the benchmark context directly:

Creek Service comparison: https://www.creekservice.org/json-schema-validation-comparison/
Creek Service performance page: https://www.creekservice.org/json-schema-validation-comparison/performance

Final takeaway

Creek Service's independent benchmark is a good reminder that JSON Schema performance is not only about raw validation speed.

It is also about how much extra work your validation architecture forces you to do.

SJF4J performs well in pure validation.

But the more important point is this:

when your data is already in Java object graphs, validating those object graphs directly is often the better design.

That is the design SJF4J is built around.

And that may be exactly why it feels so fast in real Java workloads.

Stop switching between POJO and JsonNode in Java. What if your objects themselves were the JSON tree?

Yu Han — Sun, 26 Apr 2026 13:31:15 +0000

Yu Han

Apr 26

Beyond POJO and JsonNode: A More Cohesive Way to Handle JSON in Java

#java #json #opensource

Comments

4 min read

Beyond POJO and JsonNode: A More Cohesive Way to Handle JSON in Java

Yu Han — Sun, 26 Apr 2026 13:24:54 +0000

Jackson is excellent at binding JSON to POJOs, but in real projects, JSON handling rarely ends at deserialization. After binding, we often still need to:

query nested fields
preserve unknown properties
apply partial updates
validate data against JSON Schema

That is when many codebases begin to bounce between two models—and the cost is not just conceptual, but structural.

POJO for typed business logic
JsonNode for structural operations

Every transition between POJO and JsonNode introduces friction: data copying, lost type information, or duplicated logic.

This article focuses on a question:

If Jackson already handles JSON-to-POJO mapping well, why do we still end up converting back to JsonNode for path access, patching, or validation?

And more importantly: what if we didn’t have to switch models at all?

Where the friction starts

A POJO is great for representing a stable Java model. But operations like JSON Path, JSON Patch, and JSON Schema are inherently structural.

That leads to a familiar pattern:

Order order = objectMapper.readValue(json, Order.class);

This is clean and natural. But later, requirements change:

we need to read $.customer.address.city
a PATCH request updates /items/0/price
the payload contains fields the POJO does not declare
validation rules are described as JSON Schema rather than Java annotations

So the code shifts to tree mode:

JsonNode root = objectMapper.readTree(json);
String city = root.path("customer").path("address").path("city").asText();

This works too. The problem is not either API on its own. The real friction comes from switching models inside the same workflow.

Over time, the codebase becomes fragmented:

business logic talks in fields and getters
structural logic talks in tree nodes
patching introduces another abstraction
validation may rely on yet another model

A more cohesive direction

In most JSON libraries, once the workflow becomes structural, we usually move into a dedicated tree model such as JsonNode.

SJF4J takes a different route: it removes the need for a separate tree model altogether.

Instead of introducing an AST like JsonNode, it treats ordinary Java objects themselves as nodes in a JSON-semantic tree.

In practice, that means:

a JSON object can be represented by Map, JsonObject, POJO, or JOJO
a JSON array can be represented by List, JsonArray, Java arrays, or Set
a JSON value can be represented by String, Number, Boolean, null, or adapted value types

That is the key design move.

Once these runtime objects participate in the same structural model, operations such as JsonPath, JsonPatch, and JsonSchema no longer need a separate tree representation in order to work. The object graph itself becomes the thing we navigate, patch, validate, and map.

So the real shift is not just “one more JSON library.” It is this:

instead of switching from Java objects to a JSON tree when the workflow becomes more structural,

SJF4J keeps the object graph itself structurally available from the beginning.

Why JOJO is a useful middle ground

One practical consequence of OBNT is JOJO: a typed Java object that also behaves like a JSON object.

public class Order extends JsonObject {
    private String id;
    private Customer customer;
    private List<Item> items;
}

Then you can work with the same object in multiple ways:

Order order = new Sjf4j().fromJson(json, Order.class);

order.getId();                                     // typed access
order.getStringByPath("$.customer.address.city");  // path access
order.getString("sourceSystem");                   // dynamic property

This is useful because many real payloads are only mostly stable.

In practice, upstream systems evolve faster than your Java model.

Some fields belong to the core Java model. Others are optional, evolving, or owned by upstream systems. A plain POJO can feel too closed for that. A raw tree can feel too loose. JOJO sits comfortably in between.

A small example

Imagine an external order payload like this:

{
  "id": "A1001",
  "customer": {
    "name": "Alice",
    "address": { "city": "Shanghai" }
  },
  "items": [
    { "sku": "P1", "price": 100 }
  ],
  "sourceSystem": "partner-x"
}

With a closed POJO model, sourceSystem may be ignored unless it is modeled explicitly.

With JOJO:

String source = order.getString("sourceSystem");
String city = order.getStringByPath("$.customer.address.city");

It is a small difference in code, but a big difference in modeling style: typed fields and flexible JSON-style access can live together.

JsonPath becomes more than a convenience

Because the object graph itself is navigable, JsonPath is no longer an add-on—it becomes a natural way to interact with your data.

With direct field access:

String city = order.getCustomer()
                   .getAddress()
                   .getCity();

This is perfectly fine when the structure is fixed and shallow.

But once the data becomes deeper, more dynamic, or only partially known, path-based access can be much cleaner:

String city = order.getStringByPath("$.customer.address.city");

It also scales naturally to bulk queries:

List<Integer> prices = order.findByPath("$.items[*].price", Integer.class);

Or filtered queries:

List<String> skus = order.findByPath("$.items[?@.price >= 100].sku", String.class);

No, this is not the same as direct field access in absolute raw speed. But that trade-off is often worth it. Like many higher-level abstractions in Java, it introduces some overhead while saving code, reducing traversal boilerplate, and improving flexibility.

Learn more → Navigating (JSON Path)

Patch fits naturally too

Once the object graph is treated structurally, patching no longer feels bolted on.

JsonPatch patch = JsonPatch.fromJson("""
[
  { "op": "replace", "path": "/customer/name", "value": "Alice Zhang" },
  { "op": "add", "path": "/items/0/discount", "value": 15 }
]
""");

patch.apply(order);

Or direct path mutation:

order.ensurePutByPath("$.shipping.trackingNo", "SF123456");

This is especially useful for:

HTTP PATCH endpoints
partial state updates
integration events
targeted nested mutations

Learn more → Patching (JSON Patch)

Validation stays in the same flow

Schema validation also becomes easier to place in the workflow when it operates on the same runtime structure:

SchemaValidator validator = new SchemaValidator();
boolean valid = validator.validate(order).isValid();

The benefit is not only fewer conversion steps. More importantly, query, mutation, and validation all operate with the same structural semantics.

Learn more → Validating (JSON Schema)

Final thought

JSON in Java is not just about converting strings into objects.

It is about how those objects participate in the rest of your system.

By treating ordinary objects as part of a JSON-semantic tree, SJF4J removes an entire layer of indirection—and with it, a surprising amount of complexity.

Project links:

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

A new jsonschema2jojo online tool!

Yu Han — Tue, 21 Apr 2026 00:08:37 +0000

Yu Han

Apr 20

Generating Java from JSON Schema

#java #jsonschema #opensource #productivity

Comments

5 min read

[Boost]

Yu Han — Tue, 21 Apr 2026 00:06:28 +0000

Yu Han

Apr 20

Generating Java from JSON Schema

#java #jsonschema #opensource #productivity

Comments

5 min read

Generating Java from JSON Schema

Yu Han — Mon, 20 Apr 2026 08:01:06 +0000

A new browser-based tool on sjf4j.org turns JSON Schema into Java scaffolding directly in the browser.

Paste a schema, tune the generation strategy, and get Java output immediately.

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

Forem: Yu Han

SJF4J makes Java JSON Schema validation fast not just by validating quickly, but by avoiding the extra JSON-tree step entirely.

Is SJF4J the fastest JSON Schema validator for Java?

Is SJF4J the fastest JSON Schema validator for Java?

An independent signal worth paying attention to

Why this is good news for SJF4J

1) SJF4J is fast at pure validation

2) SJF4J gets more interesting as the workflow gets more real

Why this matters beyond benchmark screenshots

A quick example

SJF4J is not just a validator benchmark story

Where to look next

Final takeaway

Stop switching between POJO and JsonNode in Java. What if your objects themselves were the JSON tree?

Beyond POJO and JsonNode: A More Cohesive Way to Handle JSON in Java

Beyond POJO and JsonNode: A More Cohesive Way to Handle JSON in Java

Where the friction starts

A more cohesive direction

Why JOJO is a useful middle ground

A small example

JsonPath becomes more than a convenience

Patch fits naturally too

Validation stays in the same flow

Final thought

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?

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.