7/23/2026 at 5:00:37 PM
A stated goal of the API is to have "low ceremony"; this seems like a lot of ceremony. IO.println(JsonObject.of(Map.of("providers",
JsonArray.of(List.of(JsonString.of("SUN"),
JsonString.of("SunRsaSign"),
JsonString.of("SunEC"))))));
Surely there could be some way of creating a JsonArray of native Java Strings, Booleans, Doubles, and Integers without requiring clients to explicitly convert each value into a JsonValue. And why am I forced to convert a native List into a JsonArray just so I can make it the value of a JsonObject?
Why can't I write this?
JsonObject.of(Map.of("providers", List.of("SUN", "SunRsaSign", SunEC"))));by dfabulich
7/23/2026 at 5:26:28 PM
There's a nice Java library called Clojure with a lightweight syntax if you need to work with data structures and concurrency in Java a lot: (println (json/generate-string {:providers ["SUN" "SunRsaSign" "SunEC"]}))by nlitened
7/23/2026 at 7:08:05 PM
You really can't appreciate how awesome Clojure is until you're coming from Java, can you...by packetlost
7/23/2026 at 8:00:38 PM
And vice versa. As someone who likes both languages, I appreciate how they both have their pros and cons. I was a Schemer before I learnt Java (when Java barely existed) and I adore Clojure, but if I were to write 10 MLOC mobile network routing and billing system, an air-traffic control system, or a credit-card transaction processing system etc. etc. that needs to evolve by a large team for 20 years, I would choose Java over Clojure any day. So I came to Java from C, C++, Scheme, and ML, and it's completely unsurprising to me why there has never existed a language that better supports large, long-lasting, important software (I'm not saying such a language couldn't exist, but it currently doesn't). And it's not just about the features Java has and, just as importantly, doesn't have (and if you think keeping features out of a programming language is easy, think again), but also how its evolution is handled.In this particular case, of course it is more straightforward to embed what is effectively an untyped language in another untyped language than in a typed language, at least while keeping the language simple and without adding features we don't wish to add (even in TypeScript, working with JSON directly requires bypassing type checks). Still, as the JEP says, there are good, popular Java libraries that offer more convenient and powerful ways of working with JSON, but that is not the purpose of this particular package.
by pron
7/23/2026 at 10:02:22 PM
Interesting how we need two sides balancing each others.by agumonkey
7/24/2026 at 4:52:51 AM
For the systems you mentioned I’d choose Erlang or Elixir over Java or Closure. The right runtime for the right problems.by nesarkvechnep
7/23/2026 at 10:20:21 PM
Dynamically typed languages by their nature always have an easier time with (de)serialization.by layer8
7/23/2026 at 8:46:24 PM
I prefer its sibling library Kotlin, from the makers of the world famous Java IDE: Jetbrains Fleetby BoorishBears
7/24/2026 at 11:48:17 AM
Unfortunately that library requires paying tribute to its owners, only made relevant thanks to shipping in phones powered by a green droid."The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin."
https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...
by pjmlp
7/24/2026 at 2:58:57 PM
Isn’t json processing still a dependency in Kotlin? I love the language but I don’t think it’s equivalent to built in json processing.by vips7L
7/23/2026 at 11:16:47 PM
I'm pretty partial to Groovy's JSON library - it has a nice syntax it just works (caveat that I had issues once where the size of the JSON was multiple megabytes and it corrupted).by jamesfinlayson
7/24/2026 at 8:53:28 PM
Ironically as a Clojure developer I would really love a JDK native JSON library that we could wrap to avoid having to ship 3rd party JSON deps. Sort of like how java.net.http made things simpler.by ramblurr
7/23/2026 at 5:56:29 PM
Java lacks the expressiveness to make it much better than this. There's a reason almost all the "replacement Java" languages add something to support DSLs, e.g. type safe builders in Kotlin [1]The kotlin stdlib-adjacent json lib does it like this
buildJsonObject {
putJsonArray("providers") {
add("SUN")
add("SunRsaSign")
add("SunEC")
}
}
by dtech
7/23/2026 at 10:26:40 PM
> Java lacks the expressiveness to make it much better than this.That's not really true. You can have a Java library providing:
Json.writeTo(System.out)
.object()
.array("providers")
.element("SUN")
.element("SunRsaSign")
.element("SunEC")
.end()
.end();
Json.writeTo(System.out)
.object()
.array("providers").withElements("SUN", "SunRsaSign", "SunEC")
.end();
This is basically a structured output iterator (or OutputStream-like) pattern. It can also support modularization such that substructures can be factored out into separate methods or lambdas, thereby also allowing loops and conditionals.
Such an API can be provided in a relatively compact fashion and would be nicer than what the JEP proposes.
by layer8
7/23/2026 at 6:06:38 PM
That's not the reason. The question was about JSON generation from existing Java types, not about a DSL. Java JSON libraries offer similar conveniences (in fact, you can be much more sophisticated, clear, and convenient than the DSL you've shown), but this particular library, as explicitly described in the JEP, is not intended to be a general-purpose JSON library, of which Java already has several good and popular ones.by pron
7/23/2026 at 6:08:58 PM
That's not what the person I replied to asked at all, arbitrary types weren't mentioned.They literally asked why they couldn't write JsonObject.of(Map.of(...))
by dtech
7/23/2026 at 6:10:50 PM
And there's nothing in Java preventing that. In fact, it is trivial to implement that exact API on top of the API proposed in the JEP.by pron
7/23/2026 at 5:59:22 PM
I'm not involved with the design of this API, but it seems to me that the issue on the JSON generation side (where you're complaining about ceremony) is feature creep. Creating the API you want on top of the proposed one is trivial (even in user code), but then where do you stop? If you have that conversion, it seems reasonable to also support, say, sets and records; maybe even enums.Indeed, Java JSON libraries typically offer all these conveniences and more, but this package is not intended to replace them - as the JEP clearly states ("It is not a goal to create an API that supplants established external JSON libraries"). It is intended to support only simple JSON tasks without requiring a library. For that goal, feature creep is particularly problematic: the more you offer (which reduces the need for the popular libraries in more situations) the greater the pressure to add even more.
Often, it's best to start with the minimum required, and then, as the API gets used in the field, see what the most valuable convenience methods to add on top.
by pron
7/23/2026 at 6:40:41 PM
POJOs and records require more configuration (e.g. Jackson's @JsonProperty, @JsonDeserialize). That could plausibly be out of scope.But for constructing JSON out of strings, numbers, booleans, lists, and maps, there's really not that much scope to creep into.
Specifically, I think it would be perfectly cromulent to have JsonArray.of() be able to support any Iterable of native Strings, Integers, Doubles, or Booleans; that doesn't feel like feature creep to me at all. It would transparently support Sets. (Right now, the API only accepts Lists of JsonValues, which is what makes the API feel so ceremonious.)
by dfabulich
7/23/2026 at 8:10:40 PM
> there's really not that much scope to creep intoFirst, we've been in this game far too long to know that this isn't the case. Second, this is only incubation. It may well be that the team behind this feature intend to add more convenience methods but wish to do it later once the core is more battle-tested. It's always best to focus on the core first and add ornamentation once you know the core is right.
by pron
7/24/2026 at 4:11:24 PM
Shouldn't the core provided by this JEP be a streaming API then, so that you can build whatever you need on top of it? But they specifically exclude that from the goals.by ptx
7/24/2026 at 11:17:25 PM
No, because the functionality this is the core of is explicitly for small, simple JSON tasks. If the core were streaming, you would need to always write quite a bit of non-trivial code for small, simple JSON tasks. Note that the lack of some convenience methods here doesn't even increase the number of lines of code needed. It just makes the lines more noisy.by pron
7/23/2026 at 7:47:25 PM
> Specifically, I think it would be perfectly cromulent to have JsonArray.of() be able to support any Iterable of native Strings, Integers, Doubles, or Booleans; that doesn't feel like feature creep to me at all.What type would that method accept? Wouldn't it need to be Object? That seems worse than boilerplate
by HiJon89
7/23/2026 at 11:36:39 PM
Where to stop is a pretty fuzzy question I suppose.In my world, I think the worst possible outcome would be a java.util.json library that does 50-95% of what I currently do with GSON or Jackson. In that scenario I still need an external dependency, and I can either ignore java.util.json or turn a codebase into an error-prone mix of both.
Maybe a good set of design considerations for java.util.json would be “what does this API need to run a CRUD app written in modern java?” Parse requests from the web, send responses to the web, and serialize/deserialize data from X database (e.g. if noSQL or jsonb). In my head “in modern java” would mean that JSON is converted to records at application boundaries
by peterabbitcook
7/24/2026 at 2:03:13 AM
> Maybe a good set of design considerations for java.util.json would be “what does this API need to run a CRUD app written in modern java?”Reading the JEP, that is not the motivation. The target is more a short script or some REPL interaction that reads JSON data from a web service and does something with it. A CRUD app likely already uses a web framework that comes with a full JSON library.
by pron
7/23/2026 at 8:17:50 PM
FWIW, in Kotlin's native JSON library, the API is almost identical. val json = JsonObject(
mapOf(
"providers" to JsonArray(
listOf(
JsonPrimitive("SUN"),
)
)
)
)
println(json)
val data = mapOf("providers" to listOf("SUN", "SunRsaSign", "SunEC"))
val kotlinxJSON = Json.encodeToJsonElement(data)
val jacksonJSON = ObjectMapper().writeValueAsString(data)by gavinray
7/24/2026 at 2:56:05 PM
I really wish the JDK devs would start using constructors again. I understand why factory methods exist but everything these days is of/from/newInstance/something else. Dart/Scala/Kotlin have all really solved this with language features and construction is uniform. For example in Dart they have factory constructors: https://dart.dev/language/constructors#factory-constructorsby vips7L
7/24/2026 at 5:46:44 PM
and for Kotlin/Scala you can use some cheeky operator overloading via companion objects. sealed Interface A {
class B: A
class C: A
companion object {
operator fun invoke(s: String) = when (s) {
"B" -> B()
"C" -> C()
}
}
}
val a = A("B")by vips7L
7/23/2026 at 6:30:32 PM
Currently, JsonObject.of has this signature: static JsonObject of(Map<String, ? extends JsonValue> map);
static JsonObject of(Map<String, ? extends Object> map);
It does seem like any serious application is going to use another library, and this will be useful for very simple json usage or single-file hello-world type programs (e.g. to go along with Implicitly Defined Classes and the Flexible Launch Protocol).
by singron
7/23/2026 at 7:19:17 PM
A Modest Proposal that will never be implemented: add an interface to String, Boolean, Integer, Long, Float and Double. Because all these types already implement "toString" (and I believe their toString representations are compatible with JSON), it can be a pure marker interface.by hyperpape
7/24/2026 at 1:09:37 AM
> I believe their toString representations are compatible with JSONNot quite. String is the big problem, since it needs to be wrapped in quotes, and special characters need to be escaped. But Float and Double are also problematic because Infinity and NaN aren't representable in json.
However, the new interface could have a "toJsonString" or maybe even a toJson method that returns a JsonValue
by thayne
7/23/2026 at 8:15:21 PM
JSON String requires escaping of control characters. .toString() on a String is (hopefully) the identity.by patrickthebold
7/23/2026 at 8:12:33 PM
For the "quick one-off script" case (where Implicitly Declared Classes shine), I think the most galling ceremony in this example is explicitly converting all N items in a list of literals into JsonValues for JsonArray.This would help a lot:
public interface JsonArray extends JsonValue {
static JsonArray of(JsonValue... elements) { ... }
static JsonArray of(String... elements) { ... }
static JsonArray of(Double... elements) { ... }
static JsonArray of(Integer... elements) { ... }
static JsonArray of(Boolean... elements) { ... }
}
IO.println(JsonObject.of(Map.of("providers",
JsonArray.of("SUN", "SunRsaSign", "SunEC"))));
JsonObject json = JsonObject.builder()
.put("name", "John")
.put("age", 30)
.put("active", true)
.put("providers", JsonArray.of("SUN", "SunEC"))
.build();
JsonObject json= JsonObject.of(Map.of(
"name", JsonString("John"),
"age", JsonNumber(30),
"active", JsonBoolean(true),
"providers", JsonArray.of(List.of(
JsonString("SUN"),
JsonString("SunRsaSign"),
JsonString("SunEC")
))
));by dfabulich
7/24/2026 at 4:43:22 PM
> java.lang.String and other types don't extend JsonValueAnd that ladies and gentlemen is what Java's re-doing of TypeClasses (called "witness" in the experiments they're doing now) are for.
by svieira
7/23/2026 at 5:39:36 PM
You almost can, with Jackson: jshell> new ObjectMapper().valueToTree(Map.of("providers", List.of("SUN", "SunRsaSign", "SunEC")));
$4 ==> {"providers":["SUN","SunRsaSign","SunEC"]}
by mechanicum
7/23/2026 at 5:38:38 PM
Yes, what's the point of JsonObject at all? Why JsonString when there is String? Why JsonArray when there is List? JDK only needs a function to convert from JSON format to the normal data structures it already has and back.by vlaaad
7/23/2026 at 5:52:32 PM
Because JSON types don't cleanly map to Java types. For example, a JSON number could be an int, a long, a double, a BigInteger, or a BigDecimal. Which of them the Java code wants is not something you can deduce (most generally, you could represent all JSON numbers as BigDecimal, but that's not very convnient in Java code, so in most cases you'd want to convert that to a primitive type of your choosing anyway). A JSON array is heterogeneous, while Java code typically want to be homogeneous. Representing a JSON array as a `List<Object>` won't work because the conversion of the element types is ambiguous (e.g. numbers).by pron
7/23/2026 at 6:34:53 PM
Yeah you could go with just Number though, and then keep almost everything a BigInteger/BigDecimal under the covers (or dynamically choose the correct class)by prpl
7/23/2026 at 7:44:20 PM
You could, but it would be significantly worse. Number and JsonNumber are nearly equivalent in this context, except that JsonNumber has the major advantage of being in the same sealed hierarchy as the other JSON types, allowing for nice pattern-matching (and BigDecimal suffers from the same downside). So you gain nothing - you have to convert to the desired type anyway - and lose quite a bit.by pron
7/23/2026 at 6:19:25 PM
Good point for parsing. However, the example is about serialization. What mapping ambiguity do you see there?by Hackbraten
7/23/2026 at 8:09:09 PM
There it's not about ambiguity: https://news.ycombinator.com/item?id=49025644by pron
7/23/2026 at 5:54:06 PM
It's pretty normal, almost all libs work this way. This way you can parse the JSON string into the matching data structure or print it into a string, and when building you can ensure it's valid JSON.by dtech
7/23/2026 at 9:27:22 PM
> Surely there could be some way of creating a JsonArray of native Java Strings, Booleans, Doubles, and Integers without requiring clients to explicitly convert each value into a JsonValueI think so to, and it surprises me that they write
“A key goal driving the recent evolution of the Java Platform has been to enable simple tasks to be accomplished more easily and with less ceremony. Features serving this goal include convenience factory methods for collections […]”
and don’t, from that, decide that this API needs such factory methods.
The API also doesn’t make JsonObject or JsonArray collections, requiring one to use ‘asMap’ or ‘asArray’ before iterating over them.
What benefit does that carry? That one can implement those interfaces as records?
by Someone
7/23/2026 at 7:57:57 PM
You can inline native type-safe JSON directly in Java with the manifold project. /*[Dude.json/] {
"Name": "Scott",
"Age": 100,
"Address": {
"Street": "345 Syracuse Way",
"City": "Atlantis"
}
}
*/
Dude dude = Dude.fromSource();
out.println(dude.getName());
out.println(dude.getAge());
out.println(dude.getAddress().getCity());
by owlstuffing
7/23/2026 at 9:10:58 PM
You could... but I view JSON as a simple format that you could write a recursive parser for in a few hundred lines yourself.Bringing in compile-time code generation just for defining static JSONs (which is not that common outside of tests, as most JSONs are serialized and deserialized at runtime) sounds like a hard sell.
by fallingbananna
7/23/2026 at 11:31:45 PM
This is just a small part of manifold’s JSON integration. And, yes, the inline aspect is mostly for testing, and it’s awesome there.by owlstuffing
7/23/2026 at 6:23:55 PM
Yeah, I agree.The clean way of doing this is to build a json marshaling mechanism for the type system as it already exists. This is doable in Java, and some json libraries (e.g. gson) are already capable of this.
I must admit I don't fully understand the motivation behind this JEP. Like when would I ever reach for this?
by marginalia_nu
7/23/2026 at 8:15:42 PM
The motivation behind this JEP is laid out in the JEP under the section "Motivation".As I understand that section (and I wasn't involved in writing this JEP), good and popular marshalling libraries for JSON already exist, and the JEP clearly states that it is not the goal to replace them or perform their role. The JEP says that this package may be what you'd reach for when a program only wants to do some very simple, small tasks with JSON data and the requirements and code size don't merit pulling in a fully-featured JSON library (e.g. when you're writing a one-file script, or exploring in JShell).
by pron
7/23/2026 at 9:10:06 PM
A stated goal of the API is to have "low ceremony" when reading arbitrary JSON files. I agree the JSON creation API looks pretty clunky, but the parsing API looks fairly simple.by wduquette
7/23/2026 at 8:37:58 PM
I was going to make fun of Java before even opening the page with something to the tune of `AbstractBeanJsonSimpleFactory` but looks like reality beat me to it, heh.by BoingBoomTschak
7/23/2026 at 5:42:40 PM
minimal-json scratches this itch really well for me. Dead simple API. Unfortunately not maintained anymore, but I'm still using it, even for new projects, because it just works so well.by RedShift1
7/23/2026 at 6:22:01 PM
Even Rust syntax is so much clean and better than this...by cute_boi