Core: Cannot able to create new object of System.Text.Json.JsonDocument

[tinyVishal]

Issue Title

I started exploring new json apis and found out that this is useful only if I have class model with me.

In some cases where I might need to create new jsondocument, it seems to be no option.

Using Newtonsoft.json I can create new json object using JContainer, there is not option to create object from AdHoc JsonDocument.

Can you please add option to create new JsonDocument without using streams.

General

Version : 3.0.100

[carlossanlop]

@ahsonkhan can you help here?

[tinyVishal]

@ahsonkhan do you need any information about this?

[ahsonkhan]

@tinyVishal - the JsonDocument APIs that were shipped in .NET Core 3.0 are "read-only", so the only way to build one up is to call the static Parse API on it, passing in the JSON payload.

It looks like you are looking for a way to build up a JsonDocument from scratch, and we are working on a solution for such a capability for 5.0 ("writable DOM", similar to JContainer/JObject/JArray in Newtonsoft.Json).

See this issue to track that feature:
https://github.com/dotnet/corefx/issues/39922

Here's the current spec (see type hierarchy around JsonNode):
https://github.com/dotnet/runtime/blob/master/src/libraries/System.Text.Json/docs/writable_json_dom_spec.md

Feel free to re-open this issue. Otherwise, please give those types a try (they are available in the 5.0 nightly builds) and provide feedback by filing issues in https://github.com/dotnet/runtime.

[drobert-bfm]

You have to be kidding me, right? You just now realize that this is needed? How far behind the curve can you possibly be?

[tinyVishal]

@drobert-bfm, do you feel, I am playing a joke :)?

I am not kidding best of my knowledge. I feel you are

[drobert-bfm]

@tinyVishal My comment wasn't directed at you, but at @ahsonkhan and Microsoft. I find it ridiculous that they shipped an API that is hobbled in such an obvious way, and that they think it fine to push it to a "Future" milestone, rather than hide their faces in shame at being called out for such a glaring design flaw.

[terrajobst]

@tinyVishal My comment wasn't directed at you, but at @ahsonkhan and Microsoft. I find it ridiculous that they shipped an API that is hobbled in such an obvious way, and that they think it fine to push it to a "Future" milestone, rather than hide their faces in shame at being called out for such a glaring design flaw.

Let's try to be constructive here. I understand that this is a limitation, but it's not "hobbled together". It was a deliberate design decision to make the DOM APIs read-only in order to provide a very low memory footprint for a DOM. We have been thinking about read/write access as well, but we didn't have time this release as we worked on other features.

[drobert-bfm]

@tinyVishal My comment wasn't directed at you, but at @ahsonkhan and Microsoft. I find it ridiculous that they shipped an API that is hobbled in such an obvious way, and that they think it fine to push it to a "Future" milestone, rather than hide their faces in shame at being called out for such a glaring design flaw.

Let's try to be constructive here. I understand that this is a limitation, but it's not "hobbled together". It was a deliberate design decision to make the DOM APIs read0only in order to provide a very low memory footprint for a DOM. We have been thinking about read/write access as well, but we didn't have time this release as we worked on other features.

I know the design philosophy, but to produce a "standard" api which does not at least equal in functionality that of the "de-facto standard" it purports to replace without a pre-determined plan to reach parity is a recipe for chaos and confusion. It would have been better to leave Newtonsoft as the favored API until such time as you had something that was feature-complete, rather than push as standard something which is inferior. The fact that you say it was "deliberately designed" that way doesn't change that fact; it may even make it worse.

You have to understand that architects and development leads have to make decisions as to the stacks they use and impose on their teams. Those decisions are made more complex every time there's a conflict between a standard "effort" and a non-standard one which advanced developers may not have any difficulties handling, but which lead to steeper learning curves for more junior developers, especially when they have to try to find proper resources to ramp on new technologies. It's much easier to provide training on the official standards than on a host of "de-facto" alternatives, but this is defeated when the standard is so deeply inferior.

Microsoft has had a long history of this kind of shenanigans, and has caused people in positions of leadership within development no end of unnecessary evaluations of alternatives and the development of transitional learning plans and technology introductions. This is only the latest in such controversies.

[terrajobst]

I know the design philosophy, but to produce a "standard" api which does not at least equal in functionality that of the "de-facto standard" it purports to replace without a pre-determined plan to reach parity is a recipe for chaos and confusion. It would have been better to leave Newtonsoft as the favored API until such time as you had something that was feature-complete, rather than push as standard something which is inferior.

We never said we're planning to replace JSON.NET. We have said very openly from the beginning that our goal is to focus on performance.

You have to understand that architects and development leads have to make decisions as to the stacks they use and impose on their teams.

I totally agree with this point.

It's much easier to provide training on the official standards than on a host of "de-facto" alternatives, but this is defeated when the standard is so deeply inferior.

While I agree that we have feature gaps, I think inferiority is also a function of desired properties, which aren't uniform across all our customers. And most of the time you can't build an API that is good at everything that is being asked of it without making compromises somewhere. For example, we heavily optimized the lower layers (reader/writer) to be performant, without sacrificing security/spec compliance. Unfortunately, this comes with complexity in API design which hurts usability and, as it is with the DOM, sometimes feature set as well.

Microsoft has had a long history of this kind of shenanigans, and has caused people in positions of leadership within development no end of unnecessary evaluations of alternatives and the development of transitional learning plans and technology introductions. This is only the latest in such controversies.

What you call shenanigans I call design and design comes with trade offs. In my opinion, the best we can do is being transparent in our design process, share previews, collect customer feedback, and address it accordingly. As I said, our goal wasn't to have one to one replacement for JSON.NET. If that would have been it, we would have just addedJSON.NET to the platform.