JEP 540: Simple JSON API (Now in Incubator)

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.

    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")

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.)

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

And that ladies and gentlemen is what Java's re-doing of TypeClasses (called "witness" in the experiments they're doing now) are for.

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")
        ))
    ));

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.

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).

I'm sure lots of them exist, but for your typical CRUD API, this has not been a phenomena I've run into.

Good, that's the least bad behavior. (Postel's law be damned)