Some insights into the JSON parser in Java _java

There have been a lot of class libraries dealing with JSON recently in research Json,java, Lib-json, Sf-json, Fastjson, and Jackson JSON. The first one does not say, performance and function are no bright spots.

The biggest advantage of Sf-json is the convenience of random reading. The code is simple:

Jsonobject json= jsonobject.fromobject (str);

Then read the field contents:

Json.getstring or getint or something like that. But work efficiency is debatable, and error prone.

Another advantage of Sf-json is that it automatically uses Unicode encoding, which is automatically converted to Unicode encoding such as \UFFFF when there are Chinese or symbols in the content. So even if there is no encoding in the response on the Web server side, there is no garbled problem in pushing JSON directly.

Fastjson, as the name suggests, is fast. There are a lot of performance comparisons on the Web, and I'm not going to say much about the performance.

Here is the function of the problem. It may be that the location is not the same, the initial fastjson is to be fast, so in the serialization and deserialization of objects a lot of effort. But there is a lack of functionality.

I don't know which version to start with the ability to sort key by dictionary. But there seems to be no way to close this feature. Sometimes I do not want the field order to be disturbed, this problem can not be solved.

The Fastjson version I use is 1.1.14. In addition Fastjson some bugs are not resolved, and are more obvious bugs. For example, in the @jsonfield note, the format parameter is used to specify how the date type data is serialized. If you use English or symbols, OK, no problem (such as YYYY-MM-DD), but in the format in the event of a Chinese error (such as yyyy MM month DD day). And after experiments, all annotations should be placed on the property getter (that is, getxxx () method), directly placed on the property is not working. In eclipse, we typically write attributes directly, and after the property is written, the getter and setter methods are generated in an automatically generated manner. If the attributes of the class change in the future, the individual prefers to delete all the getter and setter directly, and then regenerate. So if you put all the notes on the getter, I will be very careful when I delete them.

One more fatal thing is the document. Almost no comprehensive documentation was found to introduce or support Fastjson. The whole project is being held by a person named "lukewarm", and there are a lot of uncertainties.

After a personal assessment, I prefer to use the Jackson Json. The first document, the Jackson JSON official website, has detailed documentation for each version (http://jackson.codehaus.org/). In addition, the speed of the serialization and deserialization of Jackson JSON is not necessarily as slow. More importantly, its annotation support is better than Fastjson. Just say the key by dictionary sort of function, you can on the entity class directly plus @jsonpropertyorder (alphabetic=false) annotation can turn off the sorting function. Annotation support for other features is also good.

For example, the sequence of date and deserialization annotation support

@JsonSerialize (Using=dateserializer.class)
@JsonDeserialize (Using=datedeserializer.class)
Private Date birthday;

This allows you to specify a serialization and deserialization method for the Birthday field. In addition, both annotations are placed directly on the attribute, not on the getter.

For the two annotations above, this is what my serializer writes.

public class Dateserializer extends jsonserializer<date>

Jsonserializer is inherited, the serialization type specified in the generics is date, and then the following method is overridden

@Override
public void serialize (date date, Jsongenerator Gen, Serializerprovider provider) throws IOException, Jsonprocessingexception

The date that is passed in the method is the data that will be serialized, and then you can display the data arbitrarily, using gen.writestring (formatteddate) before exiting the method, to complete the serialization.

Similarly, my deserialization is written like this:

public class Datedeserializer extends jsondeserializer<date>

Jsondeserializer is inherited, the deserialization type specified in the generic is date, and then the following method is overridden

@Override
Public Date Deserialize (jsonparser parser, Deserializationcontext context) throws IOException, Jsonprocessingexception {

The return value of this method is the final content after deserialization. Method inside you can use Parser.gettext () to get to the current content to be processed. You can toss the data inside, just to get back to the date you want.

In addition, when making a service based on the Jackson JSON, you want to use the idea of generics to write an interface, the ultimate goal is to hope that the method can be different with the parameter type, the return value of the type will vary. It's a very rare way to write generics before, but that's a very basic question, but I'm stumped, and after looking at the source code for Jackson JSON, I get the hint, and it's OK to write as follows:

Public <T> T strtoobj (String jsonstr, class<t> clazz)

That's all you have to say. Assuming I have a result type object that needs to be deserialized, and there is already a JSON string jsonstr, then I just need to specify the second argument clazz to get directly to the object of the type:

Result newresult= Jsonprocessservice.strtoobj (JSONSTR, Result.class);

This does not include a cast of the (result) type before the method.

Above is just some of my humble opinion, but also ask colleagues to give a lot of advice.