Introduce class Json for constants and static factory methods?

[ralfstx]

With the constants NULL, TRUE, and FALSE defined on JsonValue, these constants are inherited by the subtypes of JsonValue. For example, the expression JsonArray.TRUE would compile although it doesn't make any sense. The same is true for static factory methods. The expression JsonArray.valueOf(true) would also compile and return JsonValue.TRUE which is not an instance of JsonArray.

Moving these constants and factory methods to a dedicated class Json would solve these issues. Moreover, it would result in shorter and more concise code:

Json.NULL, Json.TRUE, etc. instead of JsonValue.NULL, JsonValue.TRUE.

We could consider to rename the factory methods to value instead of valueOf.

Json.value(true), Json.value(23)...

This would also allow to add factory methods for arrays such as:

Json.array(23, 42), etc.

[sbandara]

This all looks really clean and would be fun to use. Since you can't override static methods, I guess you'd also move all parser access there as well?

[ralfstx]

The static readFrom methods don't have this problem. For example, JsonArray.readFrom() shadows JsonValue.readFrom(), but both methods make sense and return the expected type.

However, when this new Json class becomes the central entrypoint to the API, it would certainly make sense to provide these methods there as well, e.g. Json.readArray(), Json.readObject() ...