Mind Over Matter: A Lesson from Java/JSON Conversion
I’m a Java ecosystem person but most of the code I write is Groovy. There are occasional patches of Java, but my mind is tuned in to Groovy. In a recent project I had to stay all-Java for a while. A little data structure turned up that I decided would benefit from being converted to JSON and then stored in a database.
If you didn’t know, converting to/from JSON are one-liners i Groovy. You hardly even think about it. I had to search the ‘Net to find out how it’s done in Java these days. Gson seemed a solid candidate, but I was in for a surprise. In the end I chose a completely different approach which is also an editor’s choice.
When a Groovy person sees a JSON snippet like
{"foo-bar": 17, "bar-foo": "alpha"}
there is no raising of eyebrows. It looks very much like a Groovy map literal:
["foo-bar": 17, "bar-foo": "alpha"]
The brackets are different, a trivial point. Map literals are as natural to a Groovy geek as a cup of coffee.
Enter Java. The Java mind says, “What? There are a handful of frequently used Map implementations and another handful of more esoteric Maps. Life without strict type checking is impossible. I refuse to touch my keyboard without knowing precisely what kind of Map this is.”
The Java mind doesn’t stop there. It goes on, “JSON doesn’t call this a Map, they call it an Object. It can be an instance of whatever. By the way, how do you know what those values are? 17 could be a Number of unknown subclass, "alpha" might very well be an enum value. This is not data, it’s just handwaving.”
Gson seems to be a very solid implementation of the strict type-checking Java view of Java/JSON conversion. It includes some 30 interfaces and classes and would readily produce JSON from my little data structure with a few lines of code.
The problem is converting back from JSON. That’s when the Java nagging sets in, making even the humblest of data structures a staggering problem.
Let’s stop here to say that the Java mind answers the wrong question. Let’s back up and ask, Why do we use JSON in Java at all? There are two clear candidates,
- To serialize Java data structures
- To communicate with some non-Java entity outside the program
Gson is an ambitious answer to problem no 1, serialization. My proposition is that JSON in Java is almost exclusively used for problem no 2, communication with external entities. If you need serialization Java has it since the beginning of time.
JSON has limited expressiveness. Available compound data types are Array and Object. So why should we try to wrench full Java expressiveness into it? The external entity we are communicating with won’t profit from our implementation details. It’s better to start out from the JSON conceptual framework.
Guess what, there is such a solution, javax.json, part of Java EE. It has around a dozen interfaces and a single class in a one package. It’s all structured cleanly around JSON concepts. Very well done in my opinion.
In my case it turned out that javax.json did the job in fewer lines than Gson, and cleanly structured at that. You have to discover how it works, but then it’s quite easy to use. It’s an editor’s choice.
The lesson from this little Java/JSON data structure exercise is: The Java mindset sometimes takes you way out into a desert to languish without water. The Groovy mindset solves the problem while your cup of coffee is still hot.