Can't run anything with an import statement
That seems to be what's going on, anyway. HelloWorld works for me, but ECJ (http://cs.gmu.edu/~eclab/projects/ecj/) does not. NoClassDefFoundError when I try to run the thing, even though . is on my classpath and I'm in that directory (and yes, it's compiled), but (this is weird), with .. on my classpath, running ec.Evolve works for me from ec\, and being in ecj\ and running ec.Evolve works for me, but not being in ec\ and just running Evolve. C:\Documents and Settings\Nikola Tesla\Desktop\ecj\ecj\ec>java -classpath . Evolve
throws a NoClassDefFoundError (I have . on my CLASSPATH, but I thought that I'd double-check). There are no .jars anywhere. I've talked to someone else who can run ECJ just fine, and he just has . on his CLASSPATH. Everything that I've seen makes me think that this is a CLASSPATH proble]m, but mine looks fine to me (unless . isn't the current directory). Help? XP, JDK1.6.0_01. I've found several people saying that they got a NoClassDefFoundError on HelloWorld, but only one person saying that they could run that but not anything that imported anything, there was no solution, and that thread is in an archived forum.
e: Oh, and I forgot: javac *.java works for me, but javac *\*.java does not. It looks like my classpath isn't recursive, but I was under the impression that, for directories and not .jars, they are.
Message was edited by:
Schizoguy
[1429 byte] By [
Schizoguya] at [2007-11-27 7:55:26]
Apologies for the messed up formatting. Sun took away some of the goodies after some dickole exploited them, and I'm too lazy to clean up my stock answers at the moment.
[url=http://wiki.java.net/bin/view/Javapedia/ClassPath]Javapedia: Classpath[/url]
[url=http://java.sun.com/j2se/1.5.0/docs/tooldocs/findingclasses.html]How Classes are Found[/url]
[url=http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/classpath.html]Setting the class path (Windows)[/url]
[url=http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/classpath.html]Setting the class path (Solaris/Linux)[/url]
[url=http://www-106.ibm.com/developerworks/edu/j-dw-javaclass-i.html]Understanding the Java ClassLoader[/url]
java -cp .;<any other directories or jars> YourClassName
You get a NoClassDefFoundError message because the JVM (Java Virtual Machine) can't find your class. The way to remedy this is to ensure that your class is included in the classpath. The example assumes that you are in the same directory as the class you're trying to run.
javac -classpath .;<any additional jar files or directories> YourClassName.java
You get a "cannot resolve symbol" message because the compiler can't find your class. The way to remedy this is to ensure that your class is included in the classpath. The example assumes that you are in the same directory as the class you're trying to run.
jverda at 2007-7-12 19:36:49 >
Yes, but it should be simple. Seeing as how there are no .jars involved, I should just have to have . on my cp, right? Not to mention that D:\Apps\Eclipse\eclipse\Workspace\ecj\ecj\ec>java -classpath D:\Apps\Eclipse\ecl
ipse\Workspace\ecj\ecj\ec Evolve
and D:\Apps\Eclipse\eclipse\Workspace\ecj\ecj\ec>java -classpath D:\Apps\Eclipse\ecl
ipse\Workspace\ecj\ecj\ec\Evolve Evolve
throw a NoClassDefFoundError for me. It would look like my class isn't there, but D:\Apps\Eclipse\eclipse\Workspace\ecj\ecj\ec>java ec.Evolve
seems to work fine. It doesn't, though, and I still can't compile *\*.java, though I can *.java.
Message was edited by:
Schizoguy
> Yes, but it should be simple. Seeing as how there
> are no .jars involved, I should just have to have .
> on my cp, right?
It depends on how everything is structured.
Let's say you have the following structure:
.\A.class
.\b\c\D.class
A.java would not have a package statement. D.java would have pakage b.c;
java -cp . A
and
java -cp . b.c.D
will both work (assuming A and D both have the proper main method).
As for javac *\*.java, what exact problem do you have?
jverda at 2007-7-12 19:36:49 >
> As for javac *\*.java, what exact problem do
> you have?
javac: file not found: *\*.java
I also can't do javac *\*\*.java or *\*\*\*.java (and I'm doing those from places where there actually are those .java files) (but javac *.java seems to work fine).
Message was edited by:
Schizoguy
> > As for javac *\*.java, what exact problem
> do
> > you have?
>
> javac: file not found: *\*.java
Then this has nothing to do with javac and everything to do with Windows cmd.exe.
Try it with he dir command, and I'll bet you get the same thing.
jverda at 2007-7-12 19:36:49 >
I'm not sure what you mean. dir /s works.
> Re: Can't run anything with an import statement
There is a fundamental problem in your understanding of how import works.
import just changes scope/visibility if the imported classes during compile time so your source does not have to reference classes by their fully qualified name.
You cannot tell from Java Bytecode if the source it was compiled from imported any classes.
> Then this has nothing to do with Java and everything to do with Windows cmd.exe.
jverd,
Umm... I hate to disagree with a living god, but, Ummm... My experience is that java & javac both perform there own filename globbing on command line arguments. Which makes sense really, as it (mostly) hides the platform dependent behaviors from the java programmer.
I'm not saying that is the problem in this case, but it may well be relevant, and the the above statement is not absolutely correct, and may be misleading to the @OP. Sorry.
Keith.
> There is a fundamental problem in your understanding
> of how import works.
>
> import just changes scope/visibility if the
> imported classes during compile time so your source
> does not have to reference classes by their fully
> qualified name.
> You cannot tell from Java Bytecode if the source it
> was compiled from imported any classes.
While I'm sure that the former is the case, what's the difference on my end whether the bytecode contains the code or an address to it? All I know is that HelloWorld compiles and runs fine, but when I start putting import statements in there, things fall apart.
> > There is a fundamental problem in your
> understanding
> > of how import works.
> >
> > import just changes scope/visibility if the
> > imported classes during compile time so your
> source
> > does not have to reference classes by their fully
> > qualified name.
> > You cannot tell from Java Bytecode if the source
> it
> > was compiled from imported any classes.
>
> ... what's the difference on my end
> whether the bytecode contains the code or an address to it?
Huh?
> All I know is that HelloWorld compiles and runs fine,
> but when I start putting import statements in there, things fall apart.
The difference is; you could rewrite any source you have that uses import to use fully qualified class names instead - and you would not observe any difference in behaviour - so, although it may seem so to you, your problem has nothing to do with using import. That is a pretty big difference. Not understanding how things work makes it so much more difficult to troubleshoot.
> Not understanding how things work makes it so much more
> difficult to troubleshoot.
I shall read a guide, then, and hopefully therein I will find my answer - could you point me toward a good one? I've found several that say HOW to set up the cp, but that's really not my problem.
> I'm not sure what you mean. dir /s works.dir *\*.java does?
jverda at 2007-7-12 19:36:49 >
> > Then this has nothing to do with Java and
> everything to do with Windows cmd.exe.
>
> jverd,
>
> Umm... I hate to disagree with a living god,
I'll try to curtail my wrath.
> but,
> Ummm... My experience is that java & javac both
> perform there own filename globbing on command line
> arguments. Which makes sense really, as it (mostly)
> hides the platform dependent behaviors from the java
> programmer.
Oh? In Unix that's done by the shell, before java or javac even see it. I thought it was the same in Windows, and a quick test with the dir command seemed to support that. I could've been mistaken though.
jverda at 2007-7-12 19:36:49 >
> While I'm sure that the former is the case, what's
> the difference on my end whether the bytecode
> contains the code or an address to it?
By "contains the code or an address to it," are you talking about the code for the classes you import? The bytecode won't contain either. Import is a compile-time construct only. It has no effect at runtime. When you import something, neither the code itself nor any "pointer" to it ends up in the bytecode. Those other classes must be found at runtime using classpath.
jverda at 2007-7-12 19:36:49 >
> > Not understanding how things work makes it so much
> more
> > difficult to troubleshoot.
>
> I shall read a guide, then, and hopefully therein I
> will find my answer - could you point me toward a
> good one? I've found several that say HOW to set up
> the cp, but that's really not my problem.
Yes, it is. If you're getting that error message, then you have a classpath problem.
Did you read those links I posted earlier? Or the example I provided?
jverda at 2007-7-21 22:23:55 >
> dir *\*.java does?
No. I didn't know that dir worked that way. One directory down, dir *.java works fine.
e: You posted twice while I was typing. Setting the cp doesn't seem to be an issue for me - there are only so many times that I need to be told that to set it globally, it's an Environment Variable called CLASSPATH, but the preferred method is to set it locally, each time you need it. What goes on it, however, is another matter. Mine currently just has:
C:\Documents and Settings\Nikola Tesla>echo %CLASSPATH%
..;.;
(echoed so I know that the command prompt is seeing it).
Message was edited by:
Schizoguy
> e: You posted twice while I was typing. Setting the
> cp doesn't seem to be an issue for me - there are
> only so many times that I need to be told that to set
> it globally,
That's not what I'm telling you. In fact, I highly recommend not even having a classpath variable.
What I'm saying is that this is definitely a classpath problem, and I don't know what else to tell you about how to make it work than what I've alrady said and the links I've already posted.
> it's an Environment Variable called
> CLASSPATH, but the preferred method is to set it
> locally, each time you need it.
You mean with a -cp or -classpath command-line arg? Good. That's the better way.
jverda at 2007-7-21 22:23:55 >
There's one other possibility that has nothing to do with classpath. I don't know enough details about your code and your problem to know if this is relevant.
Classes that are in a package cannot use classes that are not. There's no way to import them and no fully-qualified name you can use that would distinguish them from a class in the same package as the current one.
jverda at 2007-7-21 22:23:55 >
Knowing what I've learned in this thread, this isn't even a Java problem. Why does dir *.java work fine for me, but when I go up and try dir *\*.java, I get
The filename, directory name, or volume label syntax is incorrect.
? Also,
> I don't know enough details about your code
It's not my code, but this is regardless now, because it looks to go deeper than that.
> Knowing what I've learned in this thread, this isn't
> even a Java problem. Why does dir *.java work fine
> for me, but when I go up and try dir *\*.java, I get
>
> The filename, directory name, or volume label
> syntax is incorrect.
?
That's some peculiarity of how cmd.exe or Windows executable handle filename globbing.
There are just a couple directories, I'd think you could do javac a\*.java b\*.java
If there are many, you might want to look into ant or maven.
http://ant.apache.org/
http://maven.apache.org/
jverda at 2007-7-21 22:23:55 >
> Knowing what I've learned in this thread, this isn't> even a Java problem. Why does dir *.java work fine> for me, but when I go up and try dir *\*.java, I getTry the following....dir /s /b *.java
> dir /s /b *.javaThanks, that worked for me. I didn't know that you could stack parameters for that. It seems obvious now, but hindsight and whatnot. NOW I have Java problems, but they'll hopefully be solved by reading those articles.
Ohhhh. Once I found the actual problem, finding the solution was easy. Jverd was right; import statements don't have anything to do with the JRE. When you call a program, you have to use its fully qualified name, even if you're already in that directory. I did not know that. I was just used to leaving things in the default package (sloppy, I know, but I never ran into a problem that way). So by being in ec\, having .. on the cp, and calling ec.Evolve, I thought I was heading back up a directory and then back down, whereas I was accidentally using its fully qualified name.
