 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2008Java CLASSPATH question
Hello, I am writing a simple application that uses the Apache Commons Codec. I'm running (or at least trying to run) this app on AIX 5.2. My app, called Xpacket, compiles fine. The class file is ~/src/ Xpacket.class $ java -classpath ~/src:~/src/commons-codec-1.3.jar Xpacket apache.lst Xpacket V2.0 Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/ commons/codec/binary/Base64 at Xpacket.main(Xpacket.java:14) The commons-codec-1.3.jar file _is_ in the directory specified in the classpath. It is readable (no perms problems). Why is this happening? Is the launcher not able to find it? BTW, the relevant lines from the application: $ cat ~/src/Xpacket.java import org.apache.commons.codec.binary.*; import java.io.*; public class Xpacket { public static void main(String[] args) { // some housekeeping // and below is the class Base64, part of commons-codec-1.3.jar outbytes =Base64.decodeBase64(ReadFile(args[0])); Many thanks in advance for your suggestions -Sam On Mar 24, 8:52 am, sam.n.seab...@gmail.com wrote: > The commons-codec-1.3.jar file _is_ in the directory specified in the > classpath. Classpath should have directories with *.class files or jar files itself. jar file is included to classpath only if it is in special directory $JAVA_HOME/jre/lib/ext All jar files from this "magic" directory are included to the classpath. Otherwise they (jar files) should be mentioned literally. Alex. http://www.myjavaserver.com/~alexfromohio/ Hi Alex, thanks for your response. Could you please clarify: > Classpath should have directories with *.class files or jar files > itself. I am specifying the JAR file in my -classpath when invoking the launcher > jar file is included to classpath only if it is in special directory > $JAVA_HOME/jre/lib/ext > > All jar files from this "magic" directory are included to the > classpath. Otherwise they (jar files) should be mentioned literally. I am specifying the JAR file _literally_ in my classpath (see marked below) $ java -classpath ~/src:~/src/commons-codec-1.3.jar Xpacket ^^^^^^^^^^^^^^^^^^^^^ Still it refuses to find it :-( Am I missing something? Please let me know. Thanks in advance! -Sam > Alex.http://www.myjavaserver.com/~alexfromohio/ sam.n.seab...@gmail.com wrote: >> The commons-codec-1.3.jar file _is_ in the directory specified in the >> classpath. > Classpath should have directories with *.class files or jar [sic] files > itself. Which is exactly what the OP did. >> $ java -classpath ~/src:~/src/commons-codec-1.3.jar Xpacket And you mention it, Alex, because ... ? > jar file is included to classpath only if it is in special directory > $JAVA_HOME/jre/lib/ext That is completely false. > All jar files from this "magic" directory are included to the > classpath. The extension directories, comprising $JAVA_HOME/jre/lib/ext/ by default, are intended to expand one's Java platform itself. They are not really for application libraries. <http://java.sun.com/javase/6/docs/technotes/tools/findingclasses.html#extclass> The OP did the correct thing by using the classpath option to the Java command. > Otherwise they (jar files) should be mentioned literally. Which is exactly what the OP did. However, it is not the only way to include JAR files. One could use the wildcard notation: java -cp $LIBRARY_ROOT/* etc. It's bad practice to put .class and .jar files in one's source directory, BTW. However, none of this addresses the OP's actual problem, which was not due to the use of the classpath option as far as I can see from here. It would help, OP, if you posted a complete example, say one which declares 'outbytes' [sic: should be camel case]. I can't see anything wrong with what you've posted so far, although you definitely should put Xpacket in a named package. That might even help. Also, change your import to a single-type import, not import-on-demand. Post a complete example with those changes, and run it to see if it helps. I happen to have the same version of the codec JAR, so I'd try a complete example.  SignatureLew > sam.n.seab...@gmail.com wrote: > >> The commons-codec-1.3.jar file _is_ in the directory specified in the [quoted text clipped - 13 lines] > > That is completely false. Wow, wow, wow. Just complete false. ;) Just try it. What we can see is simple standalone Java application. And I doubt that some special ClassLoader was used here. It's also not Application server and not some kind of framework (let's say JEE) which uses such things. Based on only information from this post There are only 2 options. 1) jar file is corrupted (which is not very possible) 2) ~ points to the directory where jar file doesn't exist. Mentioning more complicated things only confuses people. Alex. > However, it is not the only way to > include JAR files. One could use the wildcard notation: > > java -cp $LIBRARY_ROOT/* etc. If Java 1.6 (or newer when the show up). Arne > $ java -classpath ~/src:~/src/commons-codec-1.3.jar Xpacket > apache.lst > Xpacket V2.0 > Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/ > commons/codec/binary/Base64 > at Xpacket.main(Xpacket.java:14) I don't see anything wrong with this either. Maybe the java command doesn't handle the ~ in the second path? It's all I can think of. Please give us an ls listing of the relevant files, just to make sure. Also, jar tf commons-codec-1.3.jar | grep Base64 and show us the output. With your luck you got the one build of that jar file that didn't include the Base64 class. > I don't see anything wrong with this either. Maybe the java command > doesn't handle the ~ in the second path? It's all I can think of. This was it! Thanks Mark! $ java -classpath ~/src:$HOME/src/commons-codec-1.3.jar Xpacket apache.lst For some /strange/ reason, the java command (or the shell, or whatever the heck else is bent on destroying my life), did not like the second ~ in the classpath. I officially hate ~ now. BTW, I did check the jar file (which was right off the apache website), and it has these files in it: $ /usr/java14/bin/jar tf commons-codec-1.3.jar META-INF/ META-INF/MANIFEST.MF org/ org/apache/ org/apache/commons/ [snipped] META-INF/LICENSE.txt [snipped] org/apache/commons/codec/binary/Base64.class org/apache/commons/codec/binary/BinaryCodec.class [rest snipped] -Sam On Mar 24, 11:13 am, sam.n.seab...@gmail.com wrote: > > I don't see anything wrong with this either. Maybe the java command > > doesn't handle the ~ in the second path? It's all I can think of. [quoted text clipped - 9 lines] > the > classpath. I officially hate ~ now. ~ is handled by the same globbing library that expands ? and * -- so it's handled by the shell, and for what it's worth a * in the same context would likely not be expanded either. -o > For some /strange/ reason, the java command (or the shell, or whatever > the > heck else is bent on destroying my life), did not like the second ~ in > the > classpath. I officially hate ~ now. I think ~ is only expanded when it's at the beginning of a string. * and . and .. get a bit more processing. Check your man pages. > I think ~ is only expanded when it's at the beginning of a string. * > and . and .. get a bit more processing. Check your man pages. I think this is true. $ export CLASSPATH=~/src:~/src/commons-codec-1.3/commons- codec-1.3.jar $ echo $CLASSPATH /home/u232/src:/home/u232/src/commons-codec-1.3/commons-codec-1.3.jar $ java Xpacket apache.lst Xpacket V2.0 $ It appears that all ~s are expanded when put in the envvar. But: $ export CLASSPATH= $ echo $CLASSPATH $ java -classpath ~/src:~/src/commons-codec-1.3/commons-codec-1.3.jar Xpacket ax.lst Xpacket V2.0 Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/ commons/codec/binary/Base64 at Xpacket.main(Xpacket.java:14) $ When ~ is specified on java launcher cmdline, only the first one is expanded. And finally, $ java -classpath $HOME/src:$HOME/src/commons-codec-1.3/commons- codec-1.3.jar Xpacket ax.lst Xpacket V2.0 $ So, $HOME is expanded when specified on java launcher cmdline. The moral seems to be, avoid ~ (and the temptation to use it). Use full paths in CLASSPATH or use standard envvars like $HOME. -Sam Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.