How to Identify and Resolve Fastjson Feature.OrderedField NoSuchFieldError by Locating Conflicting JARs

While trying to keep JSON field order with Feature.OrderedField from Fastjson, the author added the parameter JSON.parseObject("...", Feature.OrderedField) but encountered a NoSuchFieldError for Feature.OrderedField during unit testing.

Solution 1

The first attempt was to run mvn dependency:tree to list all project dependencies, hoping an older Fastjson version was pulled transitively. The output showed only Fastjson version 1.2.58, so this hypothesis was discarded.

Solution 2

Analyzing the stack trace revealed that the missing field belonged to a class that could still be loaded. The author used reflection to obtain the JAR file containing the class:

try{
JSON.parseObject("...", Feature.OrderedField)
}catch(Throwable e){
String loc = "";
String urlLoc = "";
try{
loc = Feature.class.getProtectionDomain().getCodeSource().getLocation().getFile();
urlLoc = URLDecoder.decode(loc, "UTF-8");
}catch(Throwable e2){
// ignore
}
logger.info("** loc=" + LOCATION + "; URLLoc=" + URLLOCATION);
}

This approach successfully identified the JAR that bundled Fastjson classes.

Root Cause

The conflicting JAR turned out to be a proprietary message‑queue producer client that had the Fastjson source code repackaged inside it, resulting in duplicate class names across different JARs. Because of this tight coupling, the author chose to abandon Fastjson for this case and use Gson instead.

Summary

The article presents two ways to locate a conflicting JAR: (1) using mvn dependency:tree , which may miss hidden repackaged classes, and (2) retrieving the JAR path via the class’s protection domain, a more universal method that requires a small code change.