Investigating an Intermittent Fastjson Generic Parsing Bug in a Java Backend

The author shares a puzzling bug that appeared intermittently in a production Java backend when parsing JSON with Fastjson 1.2.29. The error message was com.alibaba.fastjson.JSONException: can not cast to String, value : {...} , which seemed simple but was hard to reproduce.

Cause

During a test, a colleague submitted a feature and the backend threw the above Fastjson conversion error. The JSON payload itself was correct, but the exception occurred only when the code was executed without a generic type parameter.

com.alibaba.fastjson.JSONException: can not cast to String, value : {...}
    at com.alibaba.fastjson.util.TypeUtils.castToInt(TypeUtils.java:564)
    at com.alibaba.fastjson.serializer.IntegerCodec.deserialze(IntegerCodec.java:89)

Initial debugging showed that adding a breakpoint made the problem disappear, while normal execution reproduced it after several runs.

Investigation (1)

The developer examined the utility method used for Lua script execution:

public
T executeLua(String luaName, Class
c, Object... args){
    String json = executor.execute(luaName, args);
    log.info("执行结果为:{}", json);
    T result = JSON.parseObject(json, c);
    return result;
}

Calling code without a generic type:

LuaResult result = executeLua("xxxx", LuaResult.class, args);

and the LuaResult class:

public class LuaResult
{
    protected String code;
    protected String msg;
    protected T data;
}

Even though the JSON matched the class structure, the intermittent error persisted.

Investigation (2)

Adding an explicit generic type using TypeReference eliminated the error:

LuaResult
> result = executeLua("xxxx", new TypeReference
>>(){}, args);

Research revealed that Fastjson versions prior to 1.2.33 cache the generic type of the previous parsing operation. When a non‑generic parse follows a generic one, Fastjson incorrectly reuses the cached generic, leading to a can not cast to int exception.

A minimal reproducing program demonstrated the bug by parsing three JSON strings in a specific order; only the third parse failed when using the older Fastjson version.

Conclusion

The intermittent "Schrödinger" bug was caused by Fastjson’s improper handling of generic type caching in versions before 1.2.33. Upgrading Fastjson to 1.2.33 or later resolves the issue, as the library now correctly parses without relying on previous generic definitions.