The “bad path element” Error

June 18, 2005 – 19:53 | java

One of the projects I'm working on requires all the 3rd party jars to have the version numbers removed from their file names, so that when that jar is updated to a new version, the jar file name wouldn't have to changed, and in the version control it would appear to be an updated jar checked in, rather than a new jar being added and the old one removed.

This caused some slight annoyance when I ran the ant script with the 5.0 javac, and with -Xlint. I kept getting these warnings turned up:

PLAIN TEXT
CODE:
  1. [javac] warning: [path] bad path element "E:\java\sandbox\lib\aspectwerkz-core-2.0.jar": no such file or directory
  2. [javac] warning: [path] bad path element "E:\java\sandbox\lib\dom4j-1.4.jar": no such file or directory
  3. [javac] warning: [path] bad path element "E:\java\sandbox\lib\qdox-1.4.jar": no such file or directory
  4. [javac] warning: [path] bad path element "E:\java\sandbox\lib\concurrent-1.3.1.jar": no such file or directory
  5. [javac] warning: [path] bad path element "E:\java\sandbox\lib\trove-1.0.2.jar": no such file or directory
  6. [javac] warning: [path] bad path element "E:\java\sandbox\lib\jrexx-1.1.1.jar": no such file or directory

Of course, all the file names above are indeed not there - they have all been renamed to, for example, dom4j.jar.

After a couple minutes of "where the hell did it pull those from?!", I noticed all these jars are used by Aspectwerkz, and interestingly the main aspectwerkz.jar itself isn't complaining. So I looked into the manifest.mf in that jar, and found out that it actually has a "Class-Path" referencing precisely those jars.

I don't know if referencing dependnet jars in manifest.mf is some good practice. I suppose it's debatable. At any rate, changing to "-Xlint:-path" eliminated all the warnings.

Trackback from your site, or follow the comments in RSS.

  1. 6 Responses to “The “bad path element” Error”

  2. Thanks - I have been getting these warnings for xerces-J_1.4.0.jar and commons-logging-1.1.jar for a while, nice to know I can hide these pointless? warnings...

    Cheers

    By tim on Nov 4, 2006

  3. Same with Apache FO - fop.jar.

    By Patrick Carroll on Jan 6, 2008

  4. Thanks a lot. I was getting these warnings and it cleared after adding "-Xlint:-path" really made difference, but still getting a ntoe:
    [javac] Note: Some input files use unchecked or unsafe operations.
    [javac] Note: Recompile with -Xlint:unchecked for details.

    I am not worried about this. Thanks again.

    regads
    Manoj

    By Manoj Puravoor on Jan 24, 2009

  5. Got rid of my nuisance javac errors thanks to this post. I appreciate you posting it.

    By Ben on Oct 8, 2009

  6. You made me curious, so I looked it up...

    http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html

    The purpose is to make it possible to shorten the -classpath argument, but it's more often annoying than not. Particularly when the classpath is wrong, or references JAR files that it doesn't need. Still, it's a nice idea and could be nice for compacting invocation commands.

    In any case, thanks for the post, this is what I was looking for!

    By Quinn Taylor on Nov 3, 2009

  7. The Class-Path attribute makes a lot of sense at run-time, but I wish the compiler wouldn't even look them up. It would not be helpful at all if it automatically finds some jar file which I left out of the compilation process on purpose.

    By Trejkaz on Sep 26, 2010

Post a Comment

The Path to Zen is proudly powered by WordPress Entries (RSS) and Comments (RSS). Designed by Bob