Using a workaround instead of going the “standard” way in parsing json

Question

I have been tasked with developing a java application that includes retrieving one property from a json response from a web server.

Normally when I parse json I go with the standard way of creating a pojo model of the json and then using the google gson library to create the object. However this time I feel that it is overkill to have to create a pojo when I am just retrieving one property from the json, and I want to use a workaround that will just splice and dice the string until I am left with the property that I want.

So my question is, would there be any downsides with doing such a workaround instead of going the standard way of using a pojo and gson?

Answer 1

Yes there is a downside: bugs in your half baked parser. Sure JSON is simple but you still can encounter tricky escaping situations.

Just use an existing tried and true JSON parsing method and save your brain cells for the harder problems.

Answer 2

To avoid creating a new Java class which maps the complete JSON response when you only need one single field of it, you could use a library like JsonSimple which represents a parsed JSON object with a HashMap. You can then retrieve the value of that one key from that HashMap without mentioning anything else it contains.

Answer 3

Premature optimization.

The major downside is the time wasted on a home made solution.

First, you'll spend time developing your solution, and then fixing bugs. If bugs there are, it may waste not only your time, but also the time of your coworkers: other developers, testers, support personnel, etc.

Then, everyone who has to read your code will have to spend extra time understanding what's happening here. One knows how to deserialize a JSON, but no other persons will be familiar with your approach.

Ideally, requirements will never change and your code won't have to be changed. In real life, things may not go well though. If requirements change (such as having to deserialize other fields or adapting your code to a change in JSON structure), it could cascade into more developer's time, more code, more bugs.

Let's say you're really fast, and really good. You finished implementing your solution in one hour. What's your hourly wage? Now in terms of saved CPU cycles, how much your custom solution saves to your employer? You get the picture.

Answer 4

The downside is your code will throw exceptions when you attempt to access a property which doesn't exist, rather than when you attempt to parse the json.

I do have a lot of sympathy for your dilemma. I had to consume a json model from a graphing plug in in c#

I went the normal way of creating classes to match the object only to find that the writer of the graphing app had fully used the 'ability' of JavaScript not to strongly type.

This resulted in an impossible to recreate model as property X could be one of 5 different models each having their own sub objects which also varied.

Fortunately c# now has the dynamic class which i was able to use. I don't believe java has an equivalent though. Possibly you could deserialise to a nested Hashtable?

Answer 5

A compact JSON parsing library is JSON-java. It doesn't map to POJO classes, it gives you a navigable representation of the parsed JSON. It's self-contained, meaning doesn't depend on other libraries (a fact that I like very much). I've used it a few times when a full fledged JSON/POJO mapper seemed overkill to me.