Is FastJson Really Faster? Benchmark vs Jackson and Gson
This article evaluates Alibaba's FastJson library by comparing its parsing speed, Maven popularity, and issue count against Jackson and Gson, presenting benchmark results, highlighting a critical bug in timestamp handling, and concluding with a recommendation to prefer Jackson for most Java projects.
FastJson Overview
FastJson is an open‑source JSON library from Alibaba that can serialize Java beans to JSON strings and deserialize JSON back to Java objects. It is widely used by Java developers who value its claimed speed advantage.
Performance Benchmark
A simple performance test was conducted on a JDK 8 environment with an AMD 3700X CPU and 3200 MHz memory. Two scenarios were measured: converting a simple object to a JSON string and parsing a JSON string back to an object, each executed ten million times. The libraries compared were FastJson, Jackson, and Google Gson.
The resulting timings (in milliseconds) show that FastJson is indeed the fastest, but only about 20% faster than Jackson, while Gson is noticeably slower.
Popularity and Community Support
Despite its speed, FastJson is far less popular than Jackson or Gson. Maven Central download statistics show FastJson’s usage is an order of magnitude lower than Jackson’s. Additionally, the FastJson repository has over 1,200 unresolved issues, indicating potential maintenance concerns.
Bug Example and Code Analysis
A specific bug was demonstrated with timestamp parsing. The following code snippet reproduces the issue, where malformed timestamp strings are incorrectly accepted while valid formats fail.
try {
String time = "1970-01-01 00:00:00";
com.alibaba.fastjson.JSONObject jsonObject = new com.alibaba.fastjson.JSONObject();
jsonObject.put("time", time);
Timestamp timestamp = jsonObject.getTimestamp("time");
System.out.println("time:" + timestamp);
} catch (Exception e) {
e.printStackTrace();
}The library’s internal parsing logic contains a flawed conditional that trims trailing zeros without proper validation, leading to incorrect handling of strings such as "1970-01-01 00:00:00.000000000.000000000".
if (strVal.endsWith(".000000000")) {
strVal = strVal.substring(0, strVal.length() - 10);
} else if (strVal.endsWith(".000000")) {
strVal = strVal.substring(0, strVal.length() - 7);
}
if (strVal.length() == 29 && strVal.charAt(4) == '-' && strVal.charAt(7) == '-' &&
strVal.charAt(10) == ' ' && strVal.charAt(13) == ':' && strVal.charAt(16) == ':' &&
strVal.charAt(19) == '.') {
// parsing logic that incorrectly accepts malformed formats
...
}Conclusion and Recommendation
While FastJson does offer a modest speed advantage, its lower adoption, large number of open issues, and the demonstrated parsing bug suggest it is not the optimal choice for most projects. Jackson, with its robust ecosystem and better community support, should be the default JSON library, and FastJson can be phased out in favor of more reliable alternatives.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Code Ape Tech Column
Former Ant Group P8 engineer, pure technologist, sharing full‑stack Java, job interview and career advice through a column. Site: java-family.cn
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
