Eric J. Bruno
Recently, after part of my hard drive crashed and I restored my Java development environment, I had trouble debugging one of my projects. This particular project was large, spread across multiple JAR files, and everything compiled just fine. However, when I went to run or debug it within my IDE, I consistently got a java.lang.NoSuchField Exception for a class member variable that was certainly there. When I ran the code from the command line via a script, it ran fine. I was perplexed.
For example, let’s say you have Library A, which depends on Library B and ibrary C. But, Library Balso depends on Library C (see Figure 1).
Although I’ve labeled and referred to each as a “Library”, they can be .jar files, IDE projects, or Java Class files—it doesn’t matter, it’s the dependency tree that’s the issue. This is normally not a big deal, but dependency trees like this can cause versioning issues, as was the case here.
The result is a verbose list of each class that’s loaded, and the class or .jar it’s loaded from with full path, such as:
[Loaded com.allure.JetStream.JetStream$JetStreamQueueScheduler from file:/Users/ericjbruno/dev/JetStream/dist/JetStream.jar]
There’s a ton of output--this is only one line as an example--but all you need to do is redirect it to a file and search for the offending class or field name. You’ll likely see multiple places where it’s getting loaded from, and one of them will assuredly be an out-of-date library (a class or .jar file). In my case, this was exactly what happened. I simply cleaned up the project paths, removed the older version of the offending .jar file, rebuilt, and I’ve been fine since.