Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Stack trace analysis: what jar is contributing class?  RSS feed

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the best approach to troubleshooting an exception using a stack trace in an environment where you're not sure which jars are being loaded?

For example, I'm trying to figure out a problem with Hibernate Tools in Eclipse. The problem involves some pretty common classes in packages such as org.apache.commons.logging and org.slf4j.

The stack trace looks like this:


Well, these classes could be from my project classpath, from the Eclipse installation or from the Hibernate Eclipse plugin.

Is there a way to determine which physical jar files are providing the classes listed in a stack trace?

I was eventually able to track the jars down, but only after combing through dozens of jar files, which involved a lot of and some of .

Thanks for being here,

GA
 
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That error looks like you are using a different version of some JAR file at runtime then you are using at compile time. So, at compile time everything is OK, the compiler gives you no errors, but at runtime Java notices that some method doesn't exist (because you are using a different version of a JAR file).

Check carefully that you are using the same versions of any libraries at compile time as you're using at runtime.
 
Glenn Asbury
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Jesper. That's good advice. Some variation of that is definitely happening. Hibernate Tools is simply making a call to log.debug(String str), but the logging implementation has its wires crossed. It's not actually a compile time vs. runtime issue because it's happening in Eclipse.

The only way I could figure out which jars were being called was to painstaking go through all of the jars and classes in both my project's classpath and Eclipse and try to guess which ones were being called based on their method definitions.

I was just wondering if there is an easier way.

Thanks again.
 
Greenhorn
Posts: 21
Eclipse IDE Java Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds like you are using Eclipse. If so there is a quick and dirty solution: holding down Ctrl (in win) or Cmd(Mac) point onto a method call that is causing the error (get to it by going backwards in the exception stacktrace). The IDE will try to load the source for the class containing that that method. The source is usually not provided for the libraries by default so on the resulting default eclipse page you will see what jar the class in question is from.

Also to consider are various plugins for eclipse. ClassPath Helper being one, but there are others.
 
Marshal
Posts: 56610
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's too complicated for "beginning". Moving discussion.
 
Glenn Asbury
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Markas. Those are good ideas.

I'm checking out Classpath Helper. Are there any other plugins along these lines that you have found useful?

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!