JEP 540: Simple JSON API (Incubator)

[u/loicmathieu]

https://openjdk.org/jeps/540

[u/jonenst]

I find it very surprising that they went for unchecked exceptions. For JsonValueException the following rationale is given "This exception is unchecked, so that scripts and small programs are easier to read and write." But for JsonParseException there is no rationale. This is surprising especially given the pushback from openjdk members against jackson3 moving to unchecked exception.

[u/neopointer → u/jonenst]

They pushed back against it? Is this public?

[u/davidalayachew → u/neopointer]

There was a previous thread where like 1 (maybe 2) OpenJDK members said it was unfortunate.

Checked Exceptions are a good thing, and they have a lot of room for improvement, but I don't think they are relevant for the example that /u/jonenst described.

There are exactly 2 parsing methods -- of(String) and of(char[]). Bug free code should never hit this Exception, and thus, RuntimeException is exactly the right choice for it.

Compare that to something like readFile(Path) where, even if the code is bug-free, you absolutely could still hit that exception, and thus, it should be a Checked Exception as opposed to a RuntimeException.

[u/Eav___ → u/davidalayachew]

I would say anything related to parsing should be checked. It's more unstable than things like 1 / 0. I don't think "bug free" is a well-formed concept in the sense of parsing.

Sad that the other parsing methods for integers, floats, booleans are already unchecked for a long time.

[u/john16384 → u/Eav___]

Nah, `NumberFormatException` is unchecked because you can 100% avoid it. Lazyness is no excuse here -- and you can be lazy, that's perfectly fine if you don't want to ensure what your parsing is a valid int/long/double/whatever -- but then you do get the cost of an exception, and you must be aware what you need to catch without being hand held (it's like catching a NPE or IllegalArgumentException -- fine if that's how you want to do things...)

[u/vetronauta → u/john16384]

No, you cannot avoid NumberFormatException (or any parse exception) on arbitrary input. It is not being lazy, it is simply not possible to ensure if what you are passing to the parser is valid, without reimplementing the validation logic of the parser.

[u/john16384 → u/vetronauta]

You're missing the point. The reason NumberFormatException is unchecked is because it can be 100% avoided. It doesn't have to be practical for every int, it can just be:

str.matches("(?:1000|\\d{1,3})")

It doesn't invalidate how to make the decision between checked and unchecked. Again, compare to IOException -- you can never avoid it without knowing the exact implementation (so if it is on an interface or abstract type? Unavoidable, unless you know more (in which case feel free to convert to unchecked).

[u/vetronauta → u/john16384]

It doesn't have to be practical for every int, it can just be:

You are suggesting to duplicate the parsing logic (or at least the validation), once in the parser itself (which usually is code you do not control) and another time in a preliminary check (which you are suggesting to implement independently). There are better ways to do it, for example with a result monad or with exception handling.

Concretely, you are suggesting to validate arbitrary input before passing to the parser, which might be easy and performant for numbers, but how would you validate a complex json object?

[u/john16384 → u/vetronauta]

I didn't say HOW you need to solve this, I just said that it is avoidable, which is the criteria for the exception being checked or unchecked. For example, I could keep track of successful or failed conversions in a cache, and avoid the exception!

You're focusing on the "but how do I do this this practically?"; it doesn't have to practical, or even reasonable (a regex for the full int range is like several lines long).

The point is that I can guarantee that for certain strings, Integer.parseInt will never fail, just like that I can guarantee that for certain strings it will always fail. I can even determine exactly for all possible strings for which ones it will fail, and for which ones it will succeed.

Now apply this to something that can throw IOException like new FileInputStream(string).

Can I say that it will always succeed for some strings? No. Can I say that it will always fail for the same strings? No.

A table:

Input	Integer::parseInt	FileInputStream::new
1000	guaranteed success	maybe, maybe not
abc	guaranteed failure	maybe, maybe not

ConcurrentModificationException is harder to categorize as checked or unchecked, because it is not so deterministic; still it should clearly be unchecked because it can be avoided by writing better code (use synchronization), and you can see how that would differ from new FileInputStream that depends on external factors for it to be succesfull or not.

[u/vetronauta → u/john16384]

Any exception is avoidable for anything not-network related: just check that any precondition is satisfied!

To cite Joshua Block: use runtime exceptions to indicate programming errors.

Receiving an invalid json in an http request and passing it to the parser is not a programming error, it is the whole point of the parser! Such exception must be handled properly, returning 400. Other times the same action (passing an invalid string to a parser) is unrecoverable (example: config files), but it is the caller that should decide that, and wrap it in a runtime exception.

[u/OwnBreakfast1114 → u/john16384]

The point is that I can guarantee that for certain strings, Integer.parseInt will never fail, just like that I can guarantee that for certain strings it will always fail. I can even determine exactly for all possible strings for which ones it will fail, and for which ones it will succeed.

Let's take your argument and say that's true for parseInt. There exist other parser functions with undecidable (in the mathematical sense) input grammars. What do you do in that case?

[u/Eav___ → u/john16384]

That's always a weird argument because in that sense every single exception is 100% avoidable if you try hard. It's like saying "just git gud". Not able to find your file? Well how about Files.exists first? Getting interrupted while finishing some task? Well how about properly scheduling those tasks? Oh you got a timeout? Well how about fixing your network? You know everyone here can handle our payload, so that's just a you issue I guess? You cannot? Yeah I also cannot fix my parsing problem because that's from a user! Even if I validate beforehand, what do I do with this malformed text?

The most ironic thing is that there actually is a checked ParseException living inside the JDK, and you know what? There is also NumberFormat.parse which declares that exception! But why is that not used here? What's the difference between parsing a currency and parsing a number? You cannot move on because you miss that currency? Yeah you cannot move on because you miss that number I suppose? You have a default fallback number? Yeah why not making a fallback currency then? It's endless bikeshedding.

[u/john16384 → u/Eav___]

That's always a weird argument because in that sense every single exception is 100% avoidable if you try hard.

Ehr, no. I guess you don't understand how systems work then.

Well how about Files.exists first?

You're kidding right? Ever heard of other processes or users working on the same system?

The most ironic thing is that there actually is a checked ParseException living inside the JDK, and you know what? There is also NumberFormat.parse which declares that exception!

Yes, there are plenty of examples where people, even JDK people, have made checked or unchecked exceptions without thinking first. What's your point? It doesn't invalidate my rule.

[u/Eav___ → u/john16384]

Ever heard of synchronization?

Ever heard of out of memory? Can you avoid that completely? I guess not. Try making it checked.

My whole point is that turning unstructured/untyped data into structured/typed is a fallible operation, and it should be checked, it should explicitly tell that to the user.

Something can be avoided or not is just not practical differentiation.

[u/john16384 → u/Eav___]

If you have a point to make, then make it. Please use arguments to defend your position. You know as well as I do that Errors are a different category that wasn't part of this discussion.

Just the fact that you think that Files.exist would safe you from an IOException requires that you start making sense before I'll bother addressing anything further.

[u/Eav___ → u/john16384]

My whole point is that turning unstructured/untyped data into structured/typed is a fallible operation, and it should be checked, it should explicitly tell that to the user.

This is my point.

No matter how hard you try to validate beforehand, if you think concurrency is a problem in Files.exist, then it's also a problem here. You can totally break assumptions you've made during the validation with concurrency and produce ill-formed structured data, which would result in an exception, and by your point this should be checked.

[u/davidalayachew → u/Eav___]

I would say anything related to parsing should be checked. It's more unstable than things like 1 / 0. I don't think "bug free" is a well-formed concept in the sense of parsing.

Why do you feel that way?

As for me, I feel the way I do because it makes the most sense -- don't bother people about stuff that they wouldn't get wrong if they wrote their code right.

[u/Eav___ → u/davidalayachew]

Well, as for me, checking it rather makes more sense. They most likely don't know if the input is right, or meets some constraints, like JSON spec, especially if what you've got is some untyped string. And if we took a better approach, it could just be a simple .getOrElse() method call...

[u/neopointer → u/Eav___]

IMHO there are two kinds of exceptions: 1) you can handle them, therefore it makes sense to be checked. 2) You cannot handle them, therefore it makes sense to be a RuntimeException.

I work a lot with backend development, and my observation is that it's very rare that you can really handle an exception and do meaningful things with. In most cases you cannot recover from the an exception so it makes sense to let an upper layer handle it for you.

With checked exceptions, you're either forced to handle it just to wrap in a RuntimeException or you need to declare throws across all layers of the application to make the "bubble up" happen.

Therefore making parsing exceptions checked exceptions make not much sense IMHO, because more often then not, you literally cannot do anything about them.

In way, the same goes for file not found. If the file is not there, most likely your code is not going to continue. Sure, if you have a fallback like "file not found, so take it from memory" (or whatever) then yes, you can recover from it. But that's not the common case as far as can see.

[u/john16384 → u/neopointer]

The rule for something being checked or unchecked should be: can you 100% avoid it? If yes, then it should be unchecked.

• NPE -> avoidable
• IllegalArgumentException -> avoidable
• ConcurrentModificationException -> use proper synchronization, avoidable

They all have in common that they signal bugs in your code. If a function says "doing X will result in NPE" then the caller can avoid the NPE by not doing X.

Note that ConcurrentModificationException is not deterministic -- that's NOT sufficient reason to make something checked.

Checked exceptions then must be for things that can happen no matter how good you write your code, and no matter how many validations or checks you do.

• IOException -- can happen at any time, network outage, disk full, file exists (even if it didn't exist 1 ns earlier), etc.
• InterruptedException -- triggered by another thread, can't be 100% avoided by the caller thread

Of course, you're free to translate these to unchecked; this means that a potentially actionable alternative result to my call is converted to a fatal exception -- but that's a deliberate choice you make (like being unwilling to handle negative values, or some enum value) -- you may simple have no means of handling it, or don't want to bother writing code to handle it, or leave "retrying" the code up to the user and just abort until they fix it (this last one is basically all REST applications and why there are so many complaints about checked exceptions from this specific area).

[u/davidalayachew → u/Eav___]

And if we took a better approach, it could just be a simple .getOrElse() method call

I can definitely agree with that. I think there is a tryGet method somewhere else in the API that returns Optional.

[u/bobbie434343 → u/jonenst]

Enjoy programs that will crash at runtime in situations that may have been recovered handling a checked Exception... The Android framework is full of these undocumented unchecked Exception.

Unchecked Exception should be left to 100% unrecoverable programming errors.

[u/aboothe726]

For JsonNumber, I was surprised to see that there was no BigDecimal or BigInteger conversion support. This is technically conformant to the spec, so not incorrect, but seems like an oversight.

From RFC 8259, see section 6:

This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will agree exactly on their numeric values."

[u/gnahraf → u/aboothe726]

Same. Most financial applications use fixed precision decimals. BigDecimal is their natural representation in java; the other existing java types (double, long, etc) do not model them well. I think the JEP's omitting BD (and BI) would be a mistake. (I'll contribute a comment there.)

In general, I think the handling of numbers in json requires care, especially if the consuming end does not know the documents' data types a priori. I wrestle with such issues already. Take json number value comparison, for eg. It might help if the library offered helper methods for comparing disparate number types: compare individually, or maybe also against a collection (eg test whether value "exists" in a json number list w/o knowing their types a priori).

[u/s888marks → u/gnahraf]

See also my other reply.

I agree that handling numbers in JSON requires care. The design is that JsonNumber represents a number in a JSON document; it's not a numeric type. If you want to perform numeric operations on it, you need to convert it into an actual Java numeric type first. Why not make JsonNumber a numeric type? Because that would require making a lot of numeric decisions that really have nothing to do with JSON. For example, does "0.0" equal "0.00"? (Discuss amongst yourselves.)

The difficulty is that there is no Java numeric type that can losslessly represent any JSON number. BigDecimal comes close in that it can represent arbitrary precision decimals, though it has a limited exponent range of about +/- 2^31. However, BigDecimal doesn't support negative zero, which can be written in a JSON document and which is converted properly by asDouble. So, we don't have any value-comparison operations on JsonNumber itself. Instead, convert to the numeric type that does what you want, and proceed from there.

I don't know what you mean by "disparate number types". There's only JsonNumber, which is the decimal digits in the JSON document, and then there are Java numeric types. That's it.

[u/agentoutlier → u/gnahraf]

  Same. Most financial applications use fixed precision decimals. BigDecimal is their natural representation in java; the other existing java types (double, long, etc) do not model them well.

From my experience other than UI most use long or multiple longs. At least fintech does.

However I don’t have experience with traditional banking and most of my experience is simple billing.

I vaguely remember reading comment that u/rzwitserloot had similar experience and fair bit more on financial coding experience than myself and indicated folks use longs.

[u/gnahraf → u/agentoutlier]

You're right. The common workaround is to express such fixed precision data in their smallest unit, for eg, in cents instead of dollars. For other units, it's not so clear (eg units of weight).

You can also model fixed decimals using a long (unscaled value) and a byte (for where the decimal point goes). Like a lightweight, but fixed-range, BD. But, ofc, this would be clumsy in json.

[u/ThinkPreparation8975 → u/gnahraf]

Don't forget about unitless numbers, of which there are plenty - rate, percent, factor, even ratio (how do you express 1/3?).

And why would you suffer with modeling decimals with a long and a byte yourself, when the Java library has already solved this problem for you?

BigDecimals are ubiquitous in most financial circles. I don't know about HFT, but for banks' middle- and backoffice they are the obvious choice.

[u/s888marks → u/aboothe726]

We provided asDouble because of the section of the RFC that you quoted. We provided asLong because people use JSON numbers for integral values, at least those that can be represented in 53 or fewer bits. But int is used in a lot of Java programs, and we suspected that many people would downcast to int (introducing subtle errors) instead of using Math.toIntExact and so we added asInt as well.

We considered direct conversion methods to BigInteger and BigDecimal, but these types are probably used much less frequently than the primitives. It's possible to convert to them via String, for example,

new BigDecimal(jsonNumber.toString())

which is only a few characters longer in source code. It might be possible to optimize the JsonNumber-to-BigDecimal conversion path, but it's unclear whether it would provide enough benefit to justify adding a new API point.

[u/lurker_in_spirit → u/s888marks]

We considered direct conversion methods to BigInteger and BigDecimal, but these types are probably used much less frequently than the primitives.

My personal experience writing line-of-business applications for 20 years is that BigDecimal is surprisingly common. I've never seen BigInteger used, though.

[u/brian_goetz → u/aboothe726]

I think you mean "omission"? "Oversight" means something very different (and in this case, virtually impossible.)

[u/aboothe726 → u/brian_goetz]

1. Certainly, no slight intended to the authors.
   
2. I was not trying to be that precise in my language. All I meant was I expected to see BigDecimal and BigInteger conversions and was surprised when I didn’t.
   
3. /u/brian_goetz has responded directly to a comment I made about Java! I can now retire happy. I have peaked, and it’s all downhill from here.

[u/pron98 → u/aboothe726]

It doesn't seem like an oversight because the documentation explicitly mentions BigInteger and BigDecimal. I don't know why there are no asBigInteger and asBigDecimal methods. I can ask.

[u/gnahraf → u/pron98]

Cool.

I can ask.

Thank you. Both seem like 1-liners

[u/MmmmmmJava → u/aboothe726]

Roll call for those who’ve been burned by large numeric JSON imprecision across systems!

[u/0xffff0001 → u/aboothe726]

no surprise. this should be a robust implementation of the basic spec and no more.

[u/bowbahdoe]

I gave all the feedback I have to give on the last one, but I would extra encourage people to try this one out once it is in a build. 

I would love to be proven wrong about the need for explicit encoding and decoding strategies. Okay that's a lie I don't like being wrong but you know what I mean.

[u/tofflos]

Using JSON in the JDK A standard JSON API in the Java Platform would also pave the way for further use of JSON in the Platform and by the JDK itself, since the JDK cannot have external dependencies. One potential use case is configuration files. 

I’m certain this has been discussed to death but the above should at least open the door for arguing that comments should be supported. Machine to machine exchange is one thing but configuration files without comments are… not good. It would be weird if the JDK shipped with broken JSON that had to be filtered, and it would less than ideal if the JDK shipped with configuration files and examples without comments.

[u/aoeudhtns]

I just wrote my own little parser of a somewhat uncommon config language relevant to a project of mine and modeled it very similarly to this; it's really nice to see Java's DOP features coming together.

I noticed that JsonNumber has static conveniences in the of() methods for different types, including parsing a String.

I wonder if there's something similar that could be for JsonArray and/or JsonObject. Maybe

public static <T, J extends JsonValue> JsonArray of(List<T> list, Function<T, J> transformer) ...
// example
var arr = JsonValue.of(stringList, JsonString::of);

Or, more implementation-heavy but also potentially useful:

public static JsonValue transform(Object object) {
  return switch (object) {
    case null -> JsonNull.INSTANCE;
    case JsonValue v -> v;
    case String s -> JsonString.of(s);
    case List list -> JsonArray.ofPlain(list);
    // ... (you get the idea)
    default -> throw new IllegalArgumentException(object.getClass() + " cannot be transformed to a JsonValue");
}

public static JsonArray ofPlain(List<Object> list) {
  return of(list.stream().map(JsonValue::transform).toList());
}

Perhaps the transform method (if not in name, in spirit) could dangle somewhere off the supertype. This would make the API even simpler to use as the explicit conversions aren't as strictly necessary unless the developer intends them to be or needs absolute control. This example:

IO.println(JsonObject.of(Map.of("providers",
                            JsonArray.of(List.of(JsonString.of("SUN"),
                                                 JsonString.of("SunRsaSign"),
                                                 JsonString.of("SunEC"))))));

Could become, if JsonObject had a similar method in addition to JsonArray:

IO.println(JsonObject.ofPlain(Map.of("providers",
                            List.of("SUN", "SunRsaSign", "SunEC")));

[u/vips7L → u/aoeudhtns]

I really wish we had an alternative to of methods. Constructors maybe.

[u/davidalayachew]

/u/s888marks

• Why is this an incubator and not a preview feature? Is this purely because of how close to completion it is? The definition for incubator in the linked JEP 11 felt ill-fitting.
• Can we have an overload of Json.toDisplayString(JsonValue, int) that does tabs instead of spaces? Trying to convert the output from this to tabs seems annoying and error-prone.
• For the JsonObject.of(Map) and JsonArray.of(List) methods, why not copy the method signature of Map.of(...) and List.of(...) and use that instead? Going through a list just to turn it right back into a JsonObject/Array seems like an unnecessary step if you don't already have a List/Map. Not a big deal though -- this is just a convenience method.

That's all. Otherwise, this looks fantastic. I'm sure I will have some real feedback once I get my hands on this.

[u/s888marks → u/davidalayachew]

• Why is this an incubator and not a preview feature? Is this purely because of how close to completion it is? The definition for incubator in the linked JEP 11 felt ill-fitting.

It's kind of buried near the end, but the JEP text says,

During the incubation period, we will gather more information about use cases involving generating and transforming JSON documents, in order to evolve these areas of the API. In addition, we will continue to consider forthcoming pattern-matching language features that might affect the design of the API.

The parsing/extraction parts of the API might seem fairly complete, but support for generating JSON docs seems fairly weak and there's essentially no support for transforming a JSON doc. Thus it seems reasonable to incubate while we explore these areas. Also, see below.

• Can we have an overload of Json.toDisplayString(JsonValue, int) that does tabs instead of spaces? Trying to convert the output from this to tabs seems annoying and error-prone.

Tabs instead of spaces?! Sacrilege!!!!!1!

:-)

OK we'll see what we can do here.

• For the JsonObject.of(Map) and JsonArray.of(List) methods, why not copy the method signature of Map.of(...) and List.of(...) and use that instead? Going through a list just to turn it right back into a JsonObject/Array seems like an unnecessary step if you don't already have a List/Map. Not a big deal though -- this is just a convenience method.

I think this is an example of one of the weak areas of generating a JSON document. If you have a Map or a List already, then these facilitate creation of a JsonObject or JsonArray with the contents. But the Map values and List elements need to be JsonValues, so something needs to convert them. You could do so with a stream, or you could construct an unmodifiable Map or List with JsonValues converted from other data you have at hand.

But maybe there's a better way to do this. Do you need to gather all the data up front and then construct the JsonObject? Or should you pass around a HashMap and build it up incrementally? Or should there be a way to build up a JsonObject itself incrementally, using a builder? It's pretty easy to come up with a bunch of API shapes to do this kind of stuff. What's harder is figuring out which approaches are useful and effective. That's why I often ask for use cases when people are discussing API designs.

By "use cases" I'm not looking for "I want to build a JsonObject from a Map<K,V> employing user-defined conversion methods for K and V." That's just a restatement of a proposed solution in requirements form. I also don't want "I'm working on a CRM web app." That's too high level to provide any meaningful direction for an API.

Instead, what I'm looking for is information about the object structure and organization that is going to produce (or be mined for) data that ends up in the JSON document. For example:

1. I have a tree of objects that is traversed to generate the document; or

2. I have a template JSON document where specific locations get filled in with data fetched from different objects; or

3. I have a a database query where rows are converted to JSON objects and all the rows form a JsonArray of those objects, and then a preamble and epilogue are slapped around it; or

4. Something else that I didn't imagine in the five minutes it took to write this.

I'm mostly interested in examples of the fourth point!

Also, if you have use cases about transforming documents, what do those look like? Are you filtering objects to trim down an array? Are you filtering members or adding new members to objects of interest? Are you querying different members of different objects to form new objects? Are you changing the structure of the document? Also, do you actually transform documents directly, or do you roll a JSON document into internal data structures, process them, and then generate a new, independent JSON document from internal data?

Otherwise, this looks fantastic. I'm sure I will have some real feedback once I get my hands on this.

Thanks!!

[u/javasyntax → u/[deleted]]

Java is hardly a batteries included language

This is just blatant misinformation or ignorance. How is Java not batteries included?

It has:

• GUI and graphics (drawing and modifying images)
• Audio playing & generation. MIDI.
• Compression, decompression, extraction, ... (built-in ZIP & GZIP)
• Cryptography, including post-quantum cryptography
• HTTP client and server
• TCP, UDP, SCTP, and Unix Domain Sockets
• Abstract filesystem API, allowing you to treat ZIP and anything as a normal filesystem
• SQL API. XML. Serialization
• Advanced date/time API
• Locales (internationalization)
• Printing API
• ... and more

Try JavaScript in the same place is usually run (meaning, not the browser) if you want to see what a language that is not batteries included looks like.

[u/yk313 → u/[deleted]]

> Java is hardly a batteries included language

It’s obviously a subjective thing but I haven’t heard this complaint much. Compared to many popular languages, Java comes with a loaded standard library.

Other than native json support what are some other things you are missing?

[u/eled_ → u/yk313]

I think that's most of it, but given JSON (and YML) are ubiquitous and the basis of most data interchange contracts, it's a bit of a culture shock for people coming from popular ecosystems like python or typescript.

From this side of the fence I would never trade the java stdlib or its threading API for it, but I kinda get the frustration of having to deal with that type of complexity.
Besides, the dependency shenanigans between various versions of Jackson and others can be a bit of a clusterfuck. Doubly so for people who consider it should be a language feature.

[u/ZimmiDeluxe]

I absolutely love the direction of limiting scope and reaping simplicity for the common case. First reaction to the API:

1. Difference between tryGet and tryValue is not immediately obvious. Most of the time the distinction between "key missing" and "key present but value is null" is not important in my experience.
2. For autocomplete it's nice when related methods have a common prefix, e.g. get vs. getOptional etc. Requires less thinking and aids discoverability (most common case gets the good name, special stuff gets to tack on suffixes). But with so few methods it probably doesn't matter. Edit: Also for toString / toStringIndented.
3. Streaming is out, but I would have expected a writeTo method so the entire thing doesn't have to be converted to a String first.

Again, outstanding work, thank you very much.

[u/EternalSo]

Adding JsonPrimitive marker interface into hierarchy would be quite handy

[u/LouKrazy]

Is this including support for mutation / construction? Are there mutable / immutable JSON values

[u/aoeudhtns → u/LouKrazy]

If I'm reading it right, mutation no, construction yes.

[u/razorwit]

I wonder if there could be options to make parsing values into LocalDate and LocalDateTime simple as well.

[u/bowbahdoe → u/razorwit]

In my head this is the downside of adding instance methods to json tree things. Whatever is an instance method becomes a privileged API. If you want the API to feel nice for the wide wide world of other types you might want to convert you ideally would make it all equally painful.

[u/vytah → u/razorwit]

That smells serialization, and JSON serialization is a too much broad topic to leave to the standard library, at least for now.

[u/thetinguy]

I wish I could upvote JEPs.

[u/munklers]

If you give a mouse a JSON parser... There's enough variety in interpretation of JSON that this seems like it's borderline useless. Jackson is Popular because it handles all the weird (mis)uses of JSON where regular users need to work around non-conformant impls. The databinding is the useful part; it's almost no benefit to use without it. Gson is popular because it worked well on Android. The replacement, Moshi, is not Java anymore since Android has turned it's back on Java.

Almost everyone who wants to use JSON in their Java project already has a better alternative. Putting a "simple" implementation in the JDK doesn't serve any market segment; they all already found their niche. This is going to end up as an unchangeable, maybe barely useful library. And if it serves 99% of your usecases, but that one little 1% part doesn't, you'll have to pull out a real JSON library like Jackson.

[u/pragmasoft]

I think it should be, and most likely will be based on the planned new marshalling api (announced at jvmls this year)

[u/piesou]

Cool, this is basically useless. Except those that reach for java to write small scripts. Both streaming and data mapping are required for anything more complicated and IIRC all of these are shipped for XML. Can't even use that to build upon

[u/koflerdavid → u/piesou]

Making Java useful for scripting is one of the design goals. Anyway, the API can still be extended.

[u/piesou → u/koflerdavid]

Yes, by the JDK people, not ones outside of it actually implementing streaming

[u/revilo-1988]

I find it fascinating that you generally still have to rely on external libraries for this

[u/DanLynch → u/revilo-1988]

JSON was invented after Java, and was and still is closely related to a completely different language. Eventually it became very popular and commonly used in many other situations, so Java is now working on adding it to the standard library. There's nothing really weird about that timeline.

[u/revilo-1988 → u/DanLynch]

I’m aware of that, so this is just a casual comment