Use GSON instead of embedded JSON parser

[Justin Richer]

The GSON library for parsing JSON is robust, mature, and very featureful. I would recommend its use instead of the json-smart library.

[Vladimir Dzhuvinov]

I had a quick look at GSON. It looks like a classic reflection-based serialiser/parser.

What is your view on making the library parser/serialiser agnostic? People often have a worked out preference for a specific JSON library, so such a feature could make it easier for people coming to the JOSE/JWT library to integrate it into their own project environment.

At NimbusDS we started with JSON Simple for our initial Json2Ldap web service because it provided a straightforward mapping between Java types and JSON : JSON objects are Map<String,Object>, JSON arrays List<Object>, numbers instances of Number, etc. Later a French developer came along and did some amazing work at improving parser performance, thus creating JSON Smart. This sped up JSON parsing in our software by a factor of 2x to 3x. The benchmarks we looked at back then showed that to be the top possible performance, and JSON Smart has remained our parser of choice since then.

The only places where the JOSE/JWT lib deals with JSON is in the JOSE header construction/parsing and in the JWT claims sets. These can quite naturally be represented as a java.util.Map, which JSON Smart and I think GSON as well should be able to serialise from / parse to.

[Justin Richer]

I haven't been in a situation where JSON parsing/serialization has been a bottleneck, so I can't comment on the relative speed of different libraries. But you're definitely right that people will want to integrate with different libraries in their own systems. I'd be happy with it being parser agnostic if possible, but the problem comes with the drop to Map<String, Object> since the "Object" gives you no type information that you can do anything useful with in code.

[Justin Richer]

Also, note that with Gson, you wouldn't need your own JSONObjectUtils class anymore.

[Vladimir Dzhuvinov]

Yes, JSONObjectUtils is something that should have been patched into the upstream JSON Smart library :)

[Vladimir Dzhuvinov]

I went through the code and made a list of all API classes that either take in or return a JSON object:

• com.nimbusds.jose.Payload
• com.nimbusds.jose.Header and all extending clases
• com.nimbusds.jwt.JWTClaimsSet

Regarding Map<String,Object>, it actually isn't that much different from other "custom" classes that represent a JSON object. Take Gson's JsonObject for instance. It essentially is a Map<String,JsonElement> with a number of helper methods for typed retrieval of the member values (very much like what JSONObjectUtils does internally I suppose). So to me, from a programmer's perspective, there isn't that much of a difference - you have to call the correct getter method for the expected value type, the library does a cast, maybe with some conversion, and returns the value.

I think that if we add Map<String,Object> support to the above 3+ classes that would actually be a simple and effective way to allow people to plug in their own JSON serialisers / parsers. It is the closest thing std Java can offer to match a JSON object. And every good JSON library should know how to handle Maps, to output a JSON object string from or to parse into.

A default internal parser / serialiser would still be a good thing to have though.

[Connect2id OSS]

Sticking with JSON Smart parser for now.