Java CLASSPATH question

[sam.n.seaborn]

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

 

[Alex.From.Ohio.Java]

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/

 

[sam.n.seaborn]

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

 

[Lew]

Classpath should have directories with *.class files or jar [sic] files
itself.

Which is exactly what the OP did.
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.

 

[Mark Space]

$ 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.

 

[sam.n.seaborn]

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

 

[Owen Jacobson]

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.

~ 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

 

[Mark Space]

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.

 

[Alex.From.Ohio.Java]

Classpath should have directories with *.class files or jar [sic] files
itself.

Which is exactly what the OP did.

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.

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.

 

[Arne Vajhøj]

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

 

[sam.n.seaborn]

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