Which Is the Right Java Abstraction for JSON

Here's a simple definition of JSON:

JSON (JavaScript Object Notation) is a lightweight data-interchange format. Its job is to deliver data payload between the client and the server.

When our server receives a JSON string, we are supposed to parse the data and load it into apt data structures depending on the server-side language. So, assuming we are using Java on the server side, we are supposed to parse it into apt data structures for Java. 

We want to try and figure out which is the right Java abstraction for JSON. To do that, let's discuss the options for receiving the data in Java. Broadly, there are three categories based on the target data structure:

1.  A POJO object hierarchy 

2. A Java collection object, such as a HashMap

3. A JSON-specific library object like JSONObject

POJO Object Hierarchy 

This is the most Java-ish way of doing it — having a statically typed hierarchy of Java objects and using a reflection-based JSON parsing library to load the data into your POJO objects. 

Advantages

1. Static typing: Your entire API format and data model are well-defined. 

2. Standard Collections: Relationships between objects are represented as standard Java util collections.

3. Clear separation: Your server code is completely isolated from the JSON protocol.

Difficulties

1. Static typing is seen as more verbose and difficult for developers.

2. There are some coding conventions to be followed for automatic mapping of fields. This creates a small learning curve.

3. Perception (misconception?) of poor performance.

4. This may require the creation of a hierarchy of transfer objects in case your domain model can itself not be directly serialized to JSON format.

Java Collection Object

This is the second most Java-ish way of doing it — using a JSON parsing library to load the data into HashMaps and ArrayLists.

Advantages

1. Standard collections: Relationships between objects are represented as standard Java util collections.

2. Clear separation: Your server code is completely isolated from the JSON protocol.

3. Easy to begin with: Like always, HashMaps look easier than static typing.

Difficulties

1. There seem to be no popular libraries that primarily target this approach. The same parsing libraries used in (1) above also allow you to do this.

Disadvantages

1. You lose out on static typing and traceability.

JSON-Specific Library Object

This is the most non-static way of doing it. Instead of converting the JSON data into your domain model, JSONObject encourages you to keep the JSON ties and these protocol-specific objects creep into your business layer.

Advantages

1. This seems to be the most beginner-friendly approach, and "easy" to use in the beginning.

2. The mapping is very straightforward.

3. This approach is made popular due to the in-built support for JSONObject in Android. 

Disadvantages

1. Dynamic typing: Your lose out on static typing and traceability.

2. Non-standard Collections: Relationships between objects are also represented as JSONObject and JSONArray. This is not a small issue. Because JSONObject and JSONArray do not play well with Java's standard Collections, it encourages more and more methods to directly support input parameters or return values as JSONObject/JSONArray.

3. No separation: Your server code continues to carry the tag of the JSON protocol even inside the business logic code.

Which method do you use currently? What are your experiences with your current approach and which approach would you recommend?