🔸 TLDR
JEP 540 brings an incubating, dependency-free JSON API to JDK 28 for simple parsing, navigation and generation.
It is intentionally NOT a Jackson/Gson replacement:
▪️ no object data binding
▪️ no streaming API
▪️ no schema validation
▪️ no permissive JSON extensions
The interesting trade-off? Reading JSON is simple. Creating it is more controversial.
JEP 540 also supersedes JEP 198, proposed back in 2014: the same year Java 8 shipped. 😅
🔸 1️⃣ ENABLE THE INCUBATOR MODULE
The API lives in jdk.incubator.json, so applications must explicitly resolve the incubator module.
#JDK28
🔸 2️⃣ PARSE JSON
Json.parse() converts an RFC 8259 JSON document into the JDK's immutable JsonValue tree.
#JSON
🔸 3️⃣ NAVIGATE WITHOUT CASTING
get(String) and get(int) live directly on JsonValue, enabling navigation without repeatedly casting to objects or arrays.
#JavaAPI
🔸 4️⃣ HANDLE OPTIONAL MEMBERS
tryGet() returns an Optional when an object member may not exist.
#Optional
🔸 5️⃣ DISTINGUISH JSON NULL
tryGet() deals with missing members, while tryValue() lets code treat JSON null explicitly.
#NullSafety
https://javafullstack2027.mystrikingly.com
🔸 6️⃣ USE PATTERN MATCHING
The sealed JSON hierarchy works naturally with modern Java pattern matching.
#PatternMatching
🔸 7️⃣ CREATE A JSON OBJECT
Construction is strongly typed: Java values are explicitly converted to JSON values.
#TypeSafety
🔸 8️⃣ CREATE A JSON ARRAY
And THIS is where the debate starts. 🔥
Several developers immediately asked why this cannot simply be:
The current design keeps JSON types explicit, but its "low ceremony" goal is already being challenged.
#DeveloperExperience
🔸 9️⃣ EXPECT STRICT JSON
❌ Trailing commas are rejected.
Comments, syntax extensions and duplicate object-member names are rejected too. Invalid input produces JsonParseException.
#FailFast
🔸 🔟 GENERATE JSON
toString() generates compact JSON while toDisplayString() produces a formatted representation.
#Serialization
🔸 WHY THIS MATTERS
For years the answer to JSON in Java has effectively been:
▪️ Jackson
▪️ Gson
▪️ JSON-P / JSON-B
▪️ another dependency
JEP 540 asks a different question:
Should parsing a small REST response or JSON file really require another library?
For large applications, Jackson isn't going anywhere.
But for scripts, JShell, small utilities, JDK internals and simple integrations, a built-in JSON API could be extremely useful.
The strongest criticism is also legitimate:
If the stated objective is "low ceremony", construction APIs such as:
repeated throughout an object feel surprisingly ceremonial.
Fortunately, that's precisely why this is an Incubator API. 🧪
Its shape can still change based on developer feedback.
https://openjdk.org/jeps/540
https://news.ycombinator.com/item?id=49023809
🔸 TAKEAWAYS
▪️ JDK 28 is getting a native SIMPLE JSON API through JEP 540.
▪️ It targets small JSON tasks, not Jackson-style data binding.
▪️ Parsing and navigation are remarkably compact.
▪️ The sealed hierarchy fits modern Java pattern matching nicely.
▪️ Parsing is intentionally strict.
▪️ JSON construction currently has significantly more ceremony.
▪️ Incubation gives the community a chance to improve that API before it stabilizes.
#Java #JDK28 #JEP540 #JSON #OpenJDK #JavaDevelopment #JavaDeveloper #Programming #SoftwareEngineering
Go further with Java certification:
Java👇
Spring👇
SpringBook👇
JavaFullstackBook👇