Identify Class Path Problems with -Xlint:Path

When I am working with developers new to Java, I often forget to tell them about the little tools that make Java development much more efficient. These are the types of tools that aren't necessarily used everyday, but are very valuable when the appropriate need arises. I remember to tell them about these tools when they run into a perplexing problem and I am helping them resolve the problem and use these tools almost without thinking about them. In this blog entry, I plan to focus on one of these tools, which is actually a non-standard javac (Sun) option: -Xlint:path.

While it is very common to see the ClassNotFoundException during Java development. Usually, such issues are easily addressed by ensuring that the appropriate JAR or directory with .class files is specified via the -classpath (-cp) option. However, this sometimes doesn't solve the problem and so the next step is often to ensure that the desired class is really located in the JAR or directory on the classpath.

Every once in a while, and especially in cases of very long classpaths, it is easy to mistype the classpath and not even notice a difference in case or missing subdirectory. These classpath issues can be troublesome for any Java developer, but they can be especially disconcerting for a new Java developer. The problem is compounded by the fact that the javac compiler doesn't automatically warn the developer when a specified classpath entry is nonexistent. When I was first learning Java, I just assumed that it would report this and I have heard other developers who are new to Java make the same assumption. Fortunately, this is when the nonstandard option (-Xlint:path) that comes with Sun's Java distribution can be used to aid in debugging classpath issues.

The -Xlint:path option is not a standard Java option, but it does identify anything on the classpath that does not actually exist. This is valuable because the normal behavior is to not report any classpath errors and so it is easy for the developer to assume that entries on the classpath were all found. The warning produced by -Xlint:path provides a clue to the developer to fix the classpath issue that is explicitly spelled out in the warning message.

The following screen snapshot indicates use of this nonstandard javac option.



As the screen snapshot above shows, the classpath entries that don't exist don't cause any errors to occur or warnings to be printed when the -Xlint:path option is not used. The javac compiler silently goes on without those classpath entries. However, specifying the -Xlint:path option leads to warning messages specifically calling out the classpath entries that cannot be found. The second example demonstrates that even multiple missing entries can be shown at once with this option.

As a final note, the classpath entries were not needed in my example anyway, so the application compiled fine with javac even when they were not found. However, in more realistic situations where the classpath actually needs to have dependent libraries on it, the -Xlint:path nonstandard javac option can help the developer to ensure that all the necessary entries are on that classpath. If a class is not found, this is especially useful in tracking down the cause.