|Since it seems I'm the only one who is concerned about the potential danger/confusion surrounding JsonValue.NULL, I will stop harping on this point. :-)|
I don't think it matters much either way for people who use the API to produce JSON responses (say, in a JAX-RS app). But I won't be surprised if this turns out to be a major criticism from the people who try to use the API to consume 3rd party REST APIs such as Twitter, Google Maps, GitHub, etc.
On 2013-01-15, at 4:44 PM, Jonathan Fuerth wrote:
On 2013-01-15, at 2:42 PM, Jitendra Kotamraju wrote:
On 01/15/2013 11:29 AM, Jonathan Fuerth
In the example that deals with null vs. missing entries ,
I see they do indeed use the Option type to represent the
possibility of a missing entry. As I said before, this is really
great but not something we should dive into in a Java API. At
least not until there's an Option<T> in the standard
Yes, I agree on that.
It appears this is coming in JDK8 (it's called Optional<T>), and that's all the more reason we shouldn't introduce our own in this API.
Digging into the code , it appears that lift-json treats
null as equivalent to JNull.
But all this aside, I feel like we should be looking for
precedent for use of a Null object in the Java SE and Java EE
libraries, not in Scala frameworks.
I still think that taking the same approach as
java.util.Map for null-vs-missing values is best, especially for
an object that implements java.util.Map.
I think that allowing null in Map itself is a mistake. Certain map
implementations like ConcurrentHashMap doesn't allow null .
Recently, I came
across the thread "map and null values" in lambda mailing list.
I see the discussion was divided. Certainly Doug Lea and Brian Goetz came out against the use of nulls in collections. But it seems that by the end of the thread, a patch was put forward that makes the new default methods on Map null-friendly. I don't think it will really matter that null mappings get skipped in streaming operations. I think it's only in special cases where we care to know the difference between null and missing.
But getting back to the question of which is more confusing, here are some examples of the type of confusion I'm talking about. These are all from the first page of Google results for "java json null value":
That's right: 5 of the top 10 results for "java json null value" are about confusion over this very issue with other JSON APIs that use a special JsonNull type rather than Java null.
If you scroll down that page a bit to "JSON.simple in Projects/Products," it looks like JSON.simple has pretty good adoption in a number of high-profile projects. I think this demonstrates that the suggestion of eschewing JsonValue.NULL isn't completely insane. :)