Those extending the non-sealed subtypes of JsonValue must conform to the requirements that are specified. The current documentation could be more clearly written as to what those requirements are. Of course we cannot enforce those requirements any more than we can enforce the requirements specified for implementations of List.
Paul. On May 19, 2025, at 1:56 PM, fo...@univ-mlv.fr wrote: ________________________________ From: "Paul Sandoz" <paul.san...@oracle.com> To: "Remi Forax" <fo...@univ-mlv.fr> Cc: "Brian Goetz" <brian.go...@oracle.com>, "core-libs-dev" <core-libs-dev@openjdk.org> Sent: Monday, May 19, 2025 10:02:50 PM Subject: Re: Towards a JSON API for the JDK On May 19, 2025, at 8:16 AM, Remi Forax <fo...@univ-mlv.fr> wrote: Okay, i've taken a look to the design and this is not pretty. That seems an exaggerated statement to me. It's a trade-off, a compromise, allowing others to implement their own parsers, perhaps from non-textual representations. So of course we cannot enforce certain constraints and we need to specify how implementations must behave. The main issue is that the javadoc claims that "Both JsonValue instances and their underlying values are immutable." but at the same time any subtypes of JsonValue is non-sealed so anyone can implement let say JsonString and adds it's own mutable implementation. You can not claim that JsonValue instances are immutable while obviously they are not. You can not claim that JsonValue subtypes are ADTs while obviously JsonValue is not algebraic. You allow anybody to write their own class inside the JsonValue hierarchy, so there is no safety, strings can be not escaped correctly, number can represent invalid values, etc. The minute I write a method that takes a JsonValue as parameter i'm writing unsafe code, You are hoping that nobody will ever extend JsonValue subtypes, that's wishful thinking, this is not a safe design ... this is not pretty. Rémi
