The CLASSPATH should not point to the bin directory of your JVM. It will work if you point to the folder containing MyClass.class, however use of CLASSPATH is considered poor practice.
Try this: java -classpath . MyClass
It's always, always, always better to explicitly set your classpath on the java command line. Now, in case I negleted to qualify that, let me mention that it's always better to specify it directly on the command line. Oh, I see I repeated myself. No worries, it's worth emphasizing
While I agree entirely, I can hear the hippies in the background mumbling the typical "you can make absolutes like that" whilst toking on a joint. Unfortunately, this remark contradicts a great many scientists and philosophers in history who have dedicated their lives to making hypotheses on some basis, which results in "absolutes" (just what is one of these anyway? This is a rhetorical question). Now technically, these hippies are right; all absolutes require context, and that has not been provided, but ironically, it is assumed by all parties involved. Given that quite often contexts cannot be provided in English since it is too inaccurate (this can be proven as an absolute in a given context with requirement analysis techniques), the best case is a paraphrase. I'll leave that up to you (whoever) to decide on, my suggested axiom is something along the lines of "you want to have a robust build environment and ensure that nothing breaks or is inadvertantly corrupted... yaddy ya (to be continued)". On the contrary, a context where the statement may be contradicted is perhaps "you wish to have an untrustworthy build environment whose results are apparantly random or left at the discretion of any ol' goose who accesses the build environment". You cannot rule out the latter case as a possibility; just that in practice, it seldom occurs.
I would say to said hippies (hippae?) that never-say-never is always implied whether explicitly stated or not � [audible huh?]. BTW, the reason I say always, always, always is my limited vocabulary. Repeating the same adjective is an inefficient but effective means of adding emphasis when the superlative is unknown. A mixed strategy can also be employed: super, super, super duper! [ August 21, 2005: Message edited by: Rick O'Shay ]
>> why you have to set '.' in the CLASSPATH on Windows, but not on linux?
You're demonstrating one of the problems: the default classpath is the current directory, by definition. Hoever, if you set it, there it goes the default. So, you probably had it set on Windows without "." in the CLASSPATH while it was not set at all on Linux.
Older Java programs will change CLASSPATH. Sometimes putting their stuff first; sometimes adding things on the end. It doesn't exist at all on some platforms. It's just a bad idea all around. [ August 21, 2005: Message edited by: Rick O'Shay ]
classdefnotfound error appears because ur classpath is not set properly.
suppose assume your .java file is present in c:\test\oo.java.
u should set your classpath to c:\test.
THis will solve ur problem
Joined: Sep 24, 2003
java.lang.NoClassDefFoundError occurs because a class loader cannot find the class that has been requested to load. It has nothing at all to do with source files, and only indirectly and within some context, does it have anything to do with the CLASSPATH environment variable, though it is a reasonable assumptions that this context applies here.
As has already been pointed out, setting the CLASSPATH environment variable should never (within quite a broad context) be done. Unset it, then try again; if that fails, post the exact issue that you are experiencing.
Thanks everyone, you are all very kind and helpful.
Joined: Sep 19, 2004
Originally posted by shekar march chandra: Hi,
THis will solve ur problem
Actually, that will cause more problems if there are already programs relying on CLASSPATH. So your suggestion, although it agrees with all the other correct solutions that preceded it, is sub-optimal.
I know this is a hard one to shake loose because most books and examples show setting the CLASSPATH, but don't set it if possible. Use -classpath. I can't say because my lips are sealed, but when it comes time for the SCJPtest, you might very will pass or fail based on your knowledge of the javac and java command line switches, particularly -classpath.
Originally posted by Rick O'Shay: >> why you have to set '.' in the CLASSPATH on Windows, but not on linux?
You're demonstrating one of the problems: the default classpath is the current directory, by definition. Hoever, if you set it, there it goes the default. So, you probably had it set on Windows without "." in the CLASSPATH while it was not set at all on Linux. [ August 21, 2005: Message edited by: Rick O'Shay ]
No, there was no CLASSPATH set on Win (Xp), nor on linux. echo %CLASSPATH% (nothing - de rien - nix) echo $CLASSPATH (nothing - de rien - nix)
Another difference: On both systems, I have set $JAVA_HOME (%JAVA_HOME%) to the java-home. On linux, I can put often used jars into $JAVA_HOME/jre/lib/ext and don't need to specify them in the classpath. On windows that is of no help.
Joined: Sep 19, 2004
If CLASSPATH is not set then, by definition, the default classpath is the current directory. Something else is wrong. I tried it on both systems and classes in my current directory were picked up. No CLASSPATH (never set it anyway) and no -classpath.
Originally posted by Stefan Wagner: Another difference: On both systems, I have set $JAVA_HOME (%JAVA_HOME%) to the java-home. On linux, I can put often used jars into $JAVA_HOME/jre/lib/ext and don't need to specify them in the classpath. On windows that is of no help.
It can be done on Windows. You need to specify the path (without using %JAVA_HOME% because that's not where the jre is). It's usually something more like C:\Program Files\Java\jre1.4.2_06\lib\ext
JavaBeginnersFaq "Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt