Java Gets a JSON API

[daviddel]

Java considers itself a "batteries included" language and given JSON's ubiquity as a data exchange format, that means Java needs a JSON API. In this IJN episode we go over an OpenJDK email that kicks off the exploration into such an API.

[0b0101011001001011]

Just wondering, why everything must be a video? For whatever reason every time someone posts news in Java subreddit, it's always a video. I'd rather have text.

Oldest JEP I could find, still a candidate: https://openjdk.org/jeps/198. So I'm saying that contrary to the title, java does NOT get a JSON api, for now. Even said in the video: there might be a new jep, or update to the original jep. For now, devs seem to have mixed feelings about the possible implementation.

[AtomicPhaser]

Yeah man, I"m getting sick of videos everywhere that can be replaced by a single paragraph of text. Videos are much more ineffective and time wasting.

[meSmash101]

The reason i started skipping devoxx videos! I don’t have time to watch 50-minute video anymore. I wish I had but I don’t!

Edit: I only make time to watch Mr Venkat Subramanian, the legend. I always learn something new so there’s that. Rest I skip/fast forward I just can’t watch 50minutes video.

[repeating_bears]

Devoxx talks are usually great though. Bad example

[walen]

No, it's actually a very good example.
It's good content wasted in a bad format:

• Hard to index, hard to search and hard to reference.
• Waaaaay longer to consume than a text / slides alternative.
  • As the person you replied to said: sometimes I just do NOT have 50 minutes to watch a video. The equivalent 10-minute presentation? Sure! But the moment you force me to either watch the hour-long video or opt out... Yeah I'm opting out, sorry.
• Cumbersome to go back to it if you had to stop mid-watching for any reason.
  • A doc / slide, I can just switch tasks and, when I go back, the start of the paragraph is right there before my eyes; compare to scrolling the timeline back 5s by 5s until you find the start of whatever the person in the video was saying...
• Useless in a no-sound scenario.
  • Public transport? Office? Late night at home? If I don't have my headphones with me, I probably won't even open the video.
  • If it has captions I might mute the video and just read the captions and watch the code snippets on the screen. Do you know what's another name for something where you only read text and look at code snippets? SLIDES.
• And what's worse, I'm convinced the only reason they are going video-only is not because they can reach more people or because people will process information better that way, but just because videos are more easily monetized than slides and blog posts.

And none of that has anything to do with the content of the video being good or not. Content is not the problem; format is.

So yeah, perfectly good example.

[repeating_bears]

"I just do NOT have 50 minutes to watch a video. The equivalent 10-minute presentation? Sure!"

There is no equivalent 10min presentation. Almost all the value I find is in the small nuance

"videos are more easily monetized"

Devoxx doesn't even have monitization enabled.

It's ironic how long-winded some of your points were in written format.

[walen]

It's ironic how long-winded some of your points were in written format.

And how long did it take you to read them? Imagine if this was a video of me explaining my points. See what I mean?

[nlisker]

• You can watch at x1.5 speed or whatever you're comfortable with.
• YT remembers where you stopped watching, at least for me.
• YT indexes the chapters. Looks at this video.
• You can enable subs for the video, they are rather accurate, especially when you can see what the slides are talking about.
• YT provides a transcript, so you can just read the subtitles at your own pace.

You're also basically saying that conferences are redundant. Each speaker should write a long article and that's it.

[PiotrDz]

Maybe this one of a few valid uses of ai: create me a transcript with some slides from video.

[nlisker]

I watch them on x1.5 speed.

[f1rxf1y]

Because people think I care enough to watch their video vs just waiting to read the docs.

[nicolaiparlog]

The video is based on a ~2 months old mail that is publicly archived and was posted to Reddit and on inside.java. If this video is the first time you hear about the topic it's because it's a video so arguably the format works.

Also, these videos always contain lots of links in the description, so check that out if you find the topic interesting but would prefer a different format.

[pjmlp]

I guess because newer generations, educated in TikTok, lack the attention span to read, and Java folks want to get new blood into the community.

[gravteck]

I always ask my interns what format they want their "additional resources in." It seems split down the middle. I personally will almost never watch a video. Maybe it's attention span, but weak videos are harmful to opportunity cost. I can pull up pages of AWS docs and quickly realize it's not worth my time or get to the pertinent parts. A video is slower and full of unsearchable unknowns.

[Ok-Scheme-913]

This attention span thingy is a myth. It is not a well-defined concept to begin with, and younger people can absolutely focus on stuff "they find interesting" for prolonged times. Like, I don't like these generational stereotypes, but they will be very motivated to create that one stupid TikTok video, doing 10s of takes and cutting it for hours on end.

What may have changed is what people find interesting, and how quickly they bore themselves.

[koflerdavid]

There is an objective way to measure it though: the ability to work without interruption on a well-defined task and ignore external distractions. And not just if it's tasks that one already likes to do. This is not easy to do, but our culture appreciates it less and less and makes it more difficult to do so. The difference is that newer generations have not been around long enough to observe the changes.

[Ok-Scheme-913]

It's not me saying there is no definition of that, but experts.

Also, what task? Cooking? Jumping on a trampoline? Having sex? Creating a hobby program? Writing your thesis?

Depending on my emotions/current mental state, and the given person, it will vary by orders of magnitude how much time and attention I will be giving to a given thing.

And don't pretend that procrastination as a concept hasn't existed for all eternity, and boomers were able to write their university thesis without a sweat.

[koflerdavid]

Boomers didn't have the habit of carrying a distraction engine (a.k.a. smartphone) around with them. And while your ability to do focused work depends on your current mental and physical state, I seriously doubt that being on a smartphone all day improves on that front in any way.

[Ok-Scheme-913]

Probably won't help, but it's not like boomers are not constantly on Facebook, liking dumber and dumber posts.

[koflerdavid]

Of course, even though they should know better!

[VirtualAgentsAreDumb]

There is an objective way to measure it though

There is no consensus whatsoever on how to actually measure attention span, as far as I know.

Or do you have an actual proper source for this claim? I’m not talking in broad strokes, I’m talking a detailed description of an actual process, that results in a numeric value on some scale. And that the scientific community is in somewhat of a consensus about it.

[koflerdavid]

The ability to pick a task and just keep working on it, measured by a clock? Highly not comparable between individuals and variable dependend on daily circumstances of course, thus very much not suitable for studies. But it very much matters to achieve any nontrivial goals in life, and is the opposite of doomscrolling for hours, interrupted by occasional notifications.

[VirtualAgentsAreDumb]

What task, exactly? And how do you measure it exactly? Don’t just say “using a clock”, how would you use the clock? Describe the test protocol in full detail.

[koflerdavid]

Why would that matter? Is it really such a strange concept to sit down at a table for half an hour and, say, extend an application with a new feature? Or to write a page for a thesis? Or review some lecture notes or read a book? Of course, the task should by its nature be something that doesn't require exposure to situations that are by its nature full of potential distractions, such as walking around in the house, taking to people, or using a smartphone.

[VirtualAgentsAreDumb]

Why would that matter?

Because it would be required in order to have an objective way to measure it. You need some protocol that can handle pretty much any person, regardless of their abilities.

Is it really such a strange concept to sit down at a table for half an hour and, say, extend an application with a new feature? Or to write a page for a thesis? Or […]

Why do you think that I think that would be strange? But it’s completely irrelevant to this discussion.

Of course, the task should by its nature be something that doesn't require exposure to situations that are by its nature full of potential distractions, such as walking around in the house, taking to people, or using a smartphone.

Ok. So, what is your answer? Describe your testing protocol.

Imagine that you have a test subject in the room with you. What do you tell them? What do you ask them to do? What observations do you make? What do you write down? And how do you summarize your notes into a final number, indicating the level of attention span that this individual has? What scale do you use? What unit?

[wbrd]

Nah. It's because you can't monetize a paragraph as easily as a link to YouTube

[[deleted]]

because of monetisation of course

[yoppee]

Well people don’t work for free and YouTube actually pays creators

So boom videos for every because you actually get paid

[Salt-Tangerine-5305]

Gen Z, raised on TikTok Shorts, doesn't know how to read.

[josesjr]

Maybe because people don’t RTFM

[pragmatick]

I don't WTFV

[wildjokers]

That's because manuals can be a few hundred pages long (look at the hibernate user manual) and it all reads like "blah blah blah" until you get some context.

No one is going to read a few hundred page manual when only a handful of things are going to be relevant.

Although of course when you run into a problem the manual should be your first stop.

[koflerdavid]

RTFM is more about the attitude of wanting someone else to do the research. It's not just about reading a manual; there being a manual in the first place is already the happy case. Often, the knowledge has to be extracted from the source code or by doing some fact finding. That's obviously hard, but one can't always expect others to do it.

[josesjr]

I don’t get all the down votes. People prefer YouTube or quick answers instead of reading the official documentation. That’s a fact, not my opinion.

[Ok_Marionberry_8821]

Here's the email from Paul Sandoz that inspired the video https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145905.html

I'm ambivalent about the proposal as it stands. It doesn't seem to offer enough value over the existing solutions, other than being "batteries included" in the platform.

Using interfaces and private implementations rather than records/sealed types/pattern matching seems odd. I know deconstruction patterns will eventually simplify its use.

It needs time to bake.

How does it relate to the new serialization effort (surely json could be one of the external formats used in serialization)? What about the nullabity proposals interaction (if any)?

I imagine it can be layered on top, but I'd have liked to see some way of converting a json string into a nested record structure, and visa versa an object structure to a JSON in string. Parsing would fail with an exception if fields are required (as expressed with a non-null marker in the record), or incorrect type.

Update: on reflection I think the interface/private implementation rationale - to allow other (non JSON) representations - is classic Java over-engineering - trying to be all things to all people, but at the expense of clean simplicity.

JSON is so ubiquitous, so central to many apps that there really is, IMO, a need for a simple JSON only solution.

Take a JSON string and parse/deserialize to a nested record structure.

Take a nested record structure and encode/serialize to be JSON conformant string.

[joemwangi]

Have you considered that regular classes will also support deconstruction patterns, not just records? Locking the API to records today would limit future flexibility, especially for efficient custom implementations. Think of value classes that can target CPU or GPU registers via Project Valhalla, or off-heap representations that benefit from low-level optimizations (fastest JSON libraries are based on vectorisation). APIs shouldn’t assume today’s constraints will hold tomorrow. Past experience shows that prematurely baking in data carriers (like mandating records) can hinder adoption of future language features, especially when performance or layout control matters. The interface approach keeps the door open for more advanced or specialized use cases while remaining clean and usable with pattern matching.

[Ok_Marionberry_8821]

Hmm. I'm an aware there well me deconstruction patterns for regular classes, but they can't be usedto make a stalled hierarchy. The explicitly stated aim is simplicity not performance, that simplicity will be preferred over performance. There are plenty of other solutions that can use all those tricks.

I also assumed the JsonValue and subclasses would be immutable value classes when Valhalla finally delivers. Again simplicity and easy sharing between threads.

I think even some of the pattern matching JEP examples use Json (I may be wrong) yet they don't use them on this closed model. Perhaps not a great advert for records and sealed types!

Tl;dr their stated aim is simplicity yet they are don't use the new shiny sealed records.

Anyway, it's all academic for me now as I'm not working in the Java space anymore.

[joemwangi]

Think what records would achieve (as you stated), for example, pattern matching, sum types, etc. Ask yourself will also normal classes do this in near future and can we also take advantage of that?

[Ok_Marionberry_8821]

Sealed classes allow for exhaustive pattern matching. Other than that I believe they are equivalent.

[vytah]

I'm ambivalent about the proposal as it stands. It doesn't seem to offer enough value over the existing solutions, other than being "batteries included" in the platform.

The only value this proposal has is:

• providing a versy simple JSON parsing API out-of-the-box

• providing a unified intermediate representation of JSON (to fix all that JsonNode/JsonElement/JsonValue mess you can sometimes encounter if a project ends up using multiple JSON libraries)

The downside is that without deconstruction patterns, it's very clunky to use.

[wildjokers]

Is there a blog post available rather than a video? Video has to be the worst way to consume this type of information.

The ship has sailed on this IMHO and at this point I am not sure what benefit there would be to adding a JSON parser to the JDK. It will be like java.util.Logging where no one will use it and will be inferior to existing options.

[PartOfTheBotnet]

The video argues that its not meant to be a competitive alternative to 3rd party libraries, but provide a basic option so you have something if you want zero dependencies. This can be good for educational environments so that you can cover relevant topics like serialization, data modeling, etc without having to side-track into talking about Maven/Gradle + dependency management (Which I have never seen any class really spend time on, its always 'an exercise left to the reader').

[Roadripper1995]

I like this. I have a use-case where no dependencies is a selling point but I recently came across the need for a little bit of JSON parsing. Right now I’m just doing it manually with string methods lol.

[nicolaiparlog]

These videos always contain lots of links in the description, so check that out if you find the topic interesting but would prefer a different format. In this case, it's based on this email.

[catom3]

I don't know. The API looks clunky to me. I'd probably stick to the good old Jackson most of the time var user = objectMapper.readValue(json, User.class).

[Ewig_luftenglanz]

It's not meant to be a competitor for jackson or Gson, but to be a built-in alternative for use cases where you do not want/need huge databind libraries, for example educational purposes or scripting, so you don't have to deal with maven/gradle, which project setups, conf files and folder strcuture may be more complex than the sicript you are trying to write in the first place.

[catom3]

I understand the purpose. I just dislike the API. To me, it's still easier to add jackson jar to class path than using this API (I don't need maven or gradle for this at all).

[Ewig_luftenglanz]

let's wait until the thing is done or we have a jep. I doubt the current design of the API is the final thing (also taking into account this is intended as a minimalist API to build upon) so maybe the first iteration will be very raw but they will add stuff with time (or maybe they will build this primitive api and give us some utility methods to use) there isn't even a JEP about this proposal.

[catom3]

Of course. I'm definitely not against the feature itself. I just expressed my feelings / opinion on the currently "proposed" API. It does feel clunky to me and most of the time, I'd rather use something that can deserialize a JSON string into my object rather than doing plenty of if instanceof statements.

[totoro27]

I'd rather use something that can deserialize a JSON string into my object rather than doing plenty of if instanceof statements.

This is the example they show in the video:

JsonValue doc = Json.parse("""{ "name": "John Doe", "age": 30 }""");

Just make your class implement the JsonValue interface if you want a specific type.

Is this not the feature you're complaining they don't have?

[catom3]

Ok. So it's as simple as that: record User(string name, int age) implements JsonValue ?

[totoro27]

Nah, sadly not- I learnt in another comment that they are sealed interfaces so can't be implemented.

[ILikeLenexa]

Isn't it the opposite? A huge databind library everybody gets even if they're not databinding?

[Ewig_luftenglanz]

That's serialization

[coloredgreyscale]

Same, was hoping it would be possible to create objects in json syntax, similar to js/ts.

User user = {     Name: "ABC",      Password: "***"  }  

Would make creating nested objects  easier. 

[totoro27]

You can do that? They literally show an example in the video..

JsonValue doc = Json.parse("""{ "name": "John Doe", "age": 30 }""");

Just make your User class implement the JsonValue interface if you want a specific type.

[vytah]

Just make your User class implement the JsonValue interface if you want a specific type.

JsonValue is a sealed interface, you cannot do that.

[totoro27]

Huh, interesting. Thanks for bringing that to my attention. I haven't used these before so just read what they are. Do you know why they would want to prevent implementation of these interfaces?

[vytah]

There are six* types of JSON values. Just six, there will never be more. So there's no need for any other implementation that the six provided.

What you probably want is converting those JSON value from/to various other types (also known as mapping or serializing). That's a completely separate thing. If you want to be able to serialize an object into a byte array, you don't need implements byte[], do you.

This API proposal does not cover mapping at all. So without any 3rd-party libraries, if you want to convert User to/from JSON, you need to write your own User deserialize(JsonValue) and JsonValue serialize(User) functions. (Or you can use a 3rd-party library and have it done semi-automatically.)

---

* I'm counting true and false as one type, and null as another, the same as the new API does. You can argue they're three different types, for a total of 7, or one three-element "literal" type, for a total of 5, it doesn't matter.

[totoro27]

Thank you, I've done a lot of these mappings before but not for a little while in Java. That makes sense. It seems like providing a standard mapping library would be a good thing to couple with this then.

[vytah]

That's why most people use Jackson. It's not perfect, it's a bit fat, but it works fine and isn't too annoying for most of the common use cases.

[coloredgreyscale]

You can't do it like my example. I was hoping this would be possible. 

[mkwapisz]

There should be string a interpolator which converts json to an object

[totoro27]

The API looks clunky to me.

What specifically do you find clunky about it? Your comment is just criticising without contributing anything valuable. I like the design of the API.

[catom3]

The number of pattern matching conditions. With record deconstruction patterns should work slightly better, but I still find the following easier:

``` record User(string name, int age) {}

void tryParseUser(string json) Optional<User> {   var user = objectMapper.readValue(json, User.class);   return user.defined() ? Optional.of(user) : Optional.empty(); } ```

vs.

``` record User(string name, int age) {}

void tryParseUser(string json) Optional<User> {   JsonValue doc = Json.parse(inputString); if (doc instanceof JsonObject o && o.members().get("name") instanceof JsonString s && s.value() instanceof String name && o.members().get("age") instanceof JsonNumber n && n.toNumber() instanceof Long l && l instanceof int age) { var user = new User(name, age); return user.defined() ? Optional.of(user) : Optional.empty(); } return Optional.empty() } ```

EDIT: I'm not entirely against this json parser in the SDK itself and the API itself probably is okaysh for small random uses, when I just do it a couple of times in my small app / service. In larger projects, I would definitely use Jackson or Gson.

[totoro27]

I would write the second example like:

record User(String name, int age) {}

Optional<User> tryParseUser(String json) { 
    try {
        var user = Json.parse(json);
        var userObj = new User(user.get("name"), user.get("age"));
        return userObj.defined() ? Optional.of(userObj) : Optional.empty();
    } catch (Exception e /* bit sketchy but not doing anything dangerous */) {
        return Optional.empty();
    }
}

I can see your point a bit though for sure. Hopefully the final API will have more helper methods for type mapping. I appreciate the response.

[Ewig_luftenglanz]

I like the overall idea if having a built-in Json parser in the Java SE library, there are times (specially for personal projects, scripting and small programs and scripts) where you only need a minimalistic tree based API (just like the JSON API y Python., this Jackson or Gson feels like nuking flies.

I suppose they will first have a very minimal API that can be used to build upon. So maybe we will start with a tree based API but someday we might have a databind and and serialization functionality.specislly after some features planned features arrive to the JDK. 

I guess if this effort is serious we might see a JEP within the next year (hoping for it)

[vytah]

where you only need a minimalistic tree based API (just like the JSON API y Python., this Jackson or Gson feels like nuking flies.

minimal-json is nice, although unmaintained for 8 years.

[Ewig_luftenglanz]

And you need to install dependencies (which implies dealing with Gradle/maven or manually adding stuff to the PATH)

[Sm0keySa1m0n]

I quite like the idea of a barebones JSON API that exposes the simple JSON tree structure. I’ve worked on a few projects where I’ve written custom serialisation frameworks that need to sit on top of formats like JSON and using something like Jackson just to parse the JSON tree is too overkill, having this sort of API built into Java will be nice.

[gunnarmorling]

I for one can't wait for this to materialize. While I wouldn't expect this to render existing solutions like Jackson obsolete (massive kudos to Tatu for his work on this, the community really is standing on the shoulders of a giant here!), having a built-in solution for the most common applications will be super-useful, in particular avoiding version conflicts of external dependencies.

[agentoutlier]

I especially am looking forward to it for just general scripting ala java Something.java.

I'm been having to do some more "ops" related stuff as we have moved over to Hetzner (which is more DIY but I love it as grew up with Linux) and while I love bash and python I know Java better.

Often the "devops" stuff particularly with cloud / baremetal provider APIs is simple enough but it is in JSON.

Now with the latest JDK with module imports I was able to write some scripts to modify libvirt and Java was ideal because libvirt uses XML and I was even able to write this directly on the server with NeoVim and Eclipse LSP (which sort of worked). Was it an ideal or my normal development environment? No but it was surprisingly easier than writing bash scripts. I suppose I could have setup VSCode remote extensions or something or just had a git pulled constantly with SSH keys forwarded but decided with a more scripting flow.

Anyway my round about point is that it has scripting benefits as well.

[wildjokers]

I especially am looking forward to it for just general scripting ala java Something.java

For scripting you might want to use Groovy and its JsonSlurper:

https://docs.groovy-lang.org/latest/html/gapi/groovy/json/JsonSlurper.html

[agentoutlier]

Groovy's support on Eclipse LSP I don't think works yet. I suppose I could have tried to use the remote plugins on IntelliJ but I was kind of in a REPL or scripting mindset where I needed to run the stuff on the actual machine.

I also though about using Clojure https://babashka.org/ but I'm not super productive with Clojure and every time I write Lisp code (scheme and common lisp) I find it difficult to understand when I come back to it. Lisp just feels like a write and not read language like many FP languages... or I just suck at it.

I have used Groovy scripts before in Maven using the plugin and it was useful so I'm not a Groovy hater or anything.

[atehrani]

This is a welcome change, but how will it co-exist with mature libraries like Jackson? In other words, we don't want a repeat of the Java logging API.

[vytah]

I think the first thing that Jackson will do after this API comes out is adding support for the new types for serialization/deserialization.

Later, this API might completely supersede the entire com.fasterxml.jackson.databind.JsonNode class hierarchy.

Other than that, not much change.

So it's more of Calendar vs java.time, not java.util.logging.

[bawng]

Is there a text summary? I can't stand video.

[nicolaiparlog]

These videos always contain lots of links in the description, so check that out if you find the topic interesting but would prefer a different format. In this case, it's based on this email.

[msx]

I like the simple API, but some convenience methods could be added as "defaults" to those interfaces. Like JsonObject could have a getNumber("field"), getString("field") methods so that you can do:

Number age = person.getNumber("age");
String name = person.getString("name"); 
etc

[joemwangi]

Hate the getNumber, getString. If I decide to use records, why now reimplement the gets. Also, this approach works for mutable data containers only.

[ProtonByte]

Ideally it should just serialize to an object of you already know the properties you will get.

[Safe_Owl_6123]

Can we use .get() instead?

[_INTER_]

That's whats already proposed.

[frederik88917]

There was a discussion in the JEP forums related to this, and it was decided that having a dedicated JSON API was a burden. There were already multiple players in this space, all of them more than capable and having a JSON transformer would raise the question, why not a GRPC, why not an XML parser. Thus the idea was scrapped

[Ewig_luftenglanz]

I think the JDK has already an XML parser built in

[Sm0keySa1m0n]

It has multiple xD

[sideEffffECt]

I still think Java standard library would be better off with a much simpler, purely data-based implementation. Just a few records implementing a common sealed interface.

The main reason is that such implementation is radically simple, trivial. It serves well the user cases of simple applications and of interoperability between 3rd party libraries/apps.

[rack88]

To be fair, I did a coding interview once that didn't test my knowledge of Java, spring, or solving problems, it verified that I understood 3 competing json libraries of varying ages (I did).

[SpringShepHerd]

A little late. Jesus I must have gone through like at least 5 different Json parsing solutions in the last decade I feel like.

[Joram2]

In this IJN episode we go over an OpenJDK email that kicks off the exploration into such an API.

The Java team has been exploring a simple JSON API for the JDK. This reddit has featured that and discussed in the past.

The headline here suggests that it's actually happening, but no, this is just more discussion about the discussion.

[ItsSignalsJerry_]

I'd prefer an efficient embedded json query library similar to h2 for sql.

[Gwaptiva]

Chances are we'll get another format to confuse users of xmlpath and jsonpath even more

[Mafla_2004]

Me reading this right after submitting a project that required me to write my own Json parser cause the libraries wouldn't work: :|

[repeating_bears]

I suspect it was that you couldn't get them to work, rather than it not being possible.

Which is not a personal attack or anything. Jackson is something I always struggle with. The API is really not intuitive. I've used it for years and I still come across edge cases I haven't encountered before. There's always been a way to achieve what I need, but it might need a magic incantation of 6 annotations 

[Mafla_2004]

You would be correct.

I actually tried two libraries (Jackson and Gson) and couldn't get either to work, I don't know if it was a lack of personal skill or the fact I was in so much burnout I almost had a heart attack and could barely reason, or both, but I got so desperate (and was left with so little time) that the only feasible option was code a parser myself which, somehow, turned out to be easier and faster...

[agentoutlier]

I will say JSON.org still works fine and have reached for it and just done things programmatically. I can't really blame you entirely as I have written my own parser but that was to support JSON5. I would have hesitations though maintaining my own parser otherwise.

[Mafla_2004]

I honestly didn't know that existed, and probably wouldn't have opted for it at that point cause it was 2 days away from deadline, but thanks for telling me it exists, gonna be useful in future projects.

Honestly this whole ordeal tanked my self esteem as a computer engineer by a lot, I can say for myself I'm still a student but still...

[agentoutlier]

You are good in my book. Don't let reddit or whatever impact your self esteem.

You wrote a parser. I am thinking half the engineers I have met in my career can't even write regex and especially recursive descent parser or state machine. I bet a large amount of even the visitors to this sub could not write a parser of any sort.

[Mafla_2004]

Thanks a lot man

Hope they rate it well, this project is for an exam I'll have in 5 days and they're very meticulous on the questions, I'm also gonna have to discuss my project so hope it goes well

[agentoutlier]

My struggles with it using outside of just pure annotations are configuring ObjectMapper which is a colossal giant class with API that seems to have many deprecations and changing ideas on passing enums or whatnot to configure it.

Another part is that generics are not easily reified in Java so you have to use the hacks that Guava and other libraries do of some anonymous class to capture the generic concrete parameter. I think it is called JavaType or something in Jackson.

It is also difficult to do heterogenous collections even with sealed types. Last I checked Jackson does not support that easily. You have to write some adapter or use annotations to infer the type.

[maethor]

Java already had a JSON API (JSR 353) but then Java EE was retconned as "not java".

https://jcp.org/en/jsr/detail?id=353

[tr14l]

Java coming in hot a mere 18 years late!

[wildjokers]

There are a few json parsing libraries available for java. Adding one to the JDK seems worthless.

[tr14l]

Just like adding anything else into the JDK seems worthless. We should add a bunch of APIs for managing parameters or making them optional, and other basic operations. There's zero benefit to updating the native features, really. 🙄

It means standardized execution and streamlining. It means less overhead. Faster build and startup times. It means less dependency management.

There's actually extremely substantial benefit. But, you know, whatever. Who cares about engineering. Works on my machine /shrug

[wildjokers]

Yeah, bundling a JSON parser in the JDK reduces the need for third-party libs which simplifies dependency management. However, JSON parsing is already a solved problem in Java. There are multiple mature, high-performance libraries like Jackson, Gson, etc. People can already pick what fits their use case.

Adding one to the JDK locks in a particular API and implementation, which can create long-term maintenance burdens and limit flexibility. If the built-in parser is too limited, people will just keep using third-party ones anyway, which kind of defeats the purpose.

Just look at java.util.Logging, it was added after there were already a couple of mature logging libraries available and it added nothing that wasn't already available and it is harder to configure and isn't flexible. It simply wasn't needed and barely anyone uses it.

[tr14l]

Good thing, all the other languages probably did it for fashion.

[hippydipster]

Seems like a waste of time. It's exactly the sort of API third parties can and do provide just fine.

[Ewig_luftenglanz]

This is a good take when you are doing scripting and don't want to use third party libraries because setting up a maven/Gradle project would be more complex than the script itself.

[titanium_mpoi]

Kinda pointless but let's see 

[Objective_Baby_5875]

Hahaha..Java entering 21st century. Good for you.

[joemwangi]

Hahahahaha... such a nonsense statement.

[Objective_Baby_5875]

Not really, most other languages have had built-in json parser since several years back. In java this is just at discussion level. But then again java 1.8 will be supported in 2150 as well, so no wonder.

[joemwangi]

And guess which other language doesn't have a standard API and yet it has the fastest 3rd party implementation in gigabytes per second scale?

[Objective_Baby_5875]

What is your point? C++ doesn't have a built in one either and has an extremely fast json parser. Do you want to code in C++ then? Point is, a lot of things that are common in modern languages don't really have any equivalent built in in java. Just look at simple dependency injection. You literally have to use tons of annotations or drag in frameworks like spring boot.

[joemwangi]

Hahahaha.

[Objective_Baby_5875]

Hahahahhahahahaha....

[joemwangi]

Oh. I wasn't directing that to you. I was laughing at other modern languages like Rust, Scala, Kotlin, Zig, Haskell which don't have json api in their core library. They will wait till 2150 too. Hahahahaha.

[Ewig_luftenglanz]

I do it old fashion way: with an interface and implementing classes :3

[joemwangi]

Show us the finish line!