Compilation question

[Tom Griffith]

Hi. If anybody has a minute, I've never fully grapsed a basic compilation tenant of java. This is when making an object reference to classA from within classB...and the error it triggers at compilation of classB.

I understand that all that is required is that classA and classB be in the same subdirectory...except I always get the "cannot find symbol: class classA" error. I've tried throwing classA.class into a jar, saving it and making a CLASSPATH reference to it when compiling classB and no dice. I've been able to kinda work around it to this point by copying classA into classB.java and compiling it, then copiling classA seperately for deployment. Anyways, thank you for reading my question and for your time.
[ November 04, 2004: Message edited by: Tom Griffith ]

[kumm redd]

hi tom
is this your question
Class B{
---
}

classA(){
B bb = new B();
}

if so, its clear , first compile class B, set classpath to current directory that you are working in . and compile A.it works fine.

sorry if i did not get your question clearly.
regards
reddy

[Tom Griffith]

Hi reddy. Thank you for that. That did clear up why I was consistently getting that error before and having to do those redundant compilations. I am not sure if this situation is different, because I get the error despite using the proper order for compilation. To be more specific, in classB, I am trying to use a reference to classA as a return type for a method in classB.

classA{
---
}

classB(){
public classA method() {
...
}
}

I compiled classA first and I get that error. I wouldn't think that would make a difference...

[Mike Gershman]

Please display your CLASSPATH and cut and paste it into a post here. Also, please tell us the directory structure in which you keep classA.java, classA.class, classB.java, and classB.class ( do a dir or ls to be sure they are there). Finally, is there anything in your javac command besides the source file name?

In my experience, the problem lies in this area.

[Tom Griffith]

Hi. Maybe I've never fully grapsped what CLASSPATH is...

1. In the autoexec, I've entered the directory where javac.exe is. In my case, c:\JAVA5

2. I save all my .java files and compile them from c:\dev

3. On the command line, I navigate to c:\dev and type...

javac classA.java

then I try to compile classB, with the object reference to classA as stated above...

javac classB.java

it gives the error. So, as an experiment, I created a jar, classA.jar, containing classA.class, and tried this from the command line...

javac classB.java -classpath .;classA.jar classB.java

Still, the same error. It's looking like I need to set CLASSPATH somewhere??

Thank you...
[ November 04, 2004: Message edited by: Tom Griffith ]

[kumm redd]

hi
the code snippet that you have written too works fine..
if its windows OS , try to set classpath in mycomputer->context menu->properties ->advanced -> environoment variables -> add that directory where the javac exists..
then you can directly use javac some.class from anywhere..

reddy

[rahul V kumar]

Does your ClassA compile ?

If it doesn't compile then try to do the following from your command prompt.
Go to the directory which has your java source files and type in the following command

set classpath=%classpath%;.;
Make sure you have c:\java5\bin or c:\java5 in your classpath

Now try compiling your source files and see.

If this works then i suggest you to set the classpath properly by going to your system environment variables.

[Joel McNary]

Java compilation will automatically try to locate and compile, if needed any classes that you have in the class that you are compiling.

Thus, if you have a ClassA.java and a ClassB.java which uses ClassA, then when you compile ClassB, the compiler will do the following:

1). Locate the ClassA.class file. It has to exist in the CLASSPATH, which is a listing of directories where your Java classes are located (if your class is in a package, then the package must be structured underneath a directory in the classpath

2). If the ClassA.class file does not exist, the Compiler will locate the ClassA.java file and attempt to compile it, in order to produce the ClassA.class file. This location is acheived in the same manner as above.

3). The compiler will continue with the compilation of ClassB

Foe a description of what the CLASSPATH is, see the FAQ:
How To Set The Classpath

[Tom Griffith]

Thanks a lot for the responses guys. Knowing that about CLASSPATH, when I saved classA to a jar and typed...

javac -classpath .;classA.jar classB.java

at the comand line, shouldn't that have found classA?

[Tom Griffith]

Hi. If someboyd has a minute, I jsut need to confirm this...

~should~ classB see classA if this is entered on the command line?...

javac -classpath .;classA.jar classB.java

if classA.class is uploaded to classA.jar? Thank you...

[Mike Gershman]

I save all my .java files and compile them from c:\dev

Check that your .class files are also going into c:\dev
If so, add c:\dev to your CLASSPATH.

Remember that CLASSPATH entries are separated by ;

[Layne Lund]

Originally posted by Tom Griffith:
Hi. Maybe I've never fully grapsped what CLASSPATH is...

1. In the autoexec, I've entered the directory where javac.exe is. In my case, c:\JAVA5

2. I save all my .java files and compile them from c:\dev

3. On the command line, I navigate to c:\dev and type...

javac classA.java

then I try to compile classB, with the object reference to classA as stated above...

javac classB.java

it gives the error. So, as an experiment, I created a jar, classA.jar, containing classA.class, and tried this from the command line...

javac classB.java -classpath .;classA.jar classB.java

Still, the same error. It's looking like I need to set CLASSPATH somewhere??

Thank you...

[ November 04, 2004: Message edited by: Tom Griffith ]

Step 1 above, should be referring to the PATH variable. This is very different from CLASSPATH. PATH is used by the operating system to locate programs to execute even if you are not in the same directory as the program's executable. CLASSPATH, on the other hand, is specific to Java. As mentioned in this thread, it helps the Java compiler and the JVM to locate classes to use.

HTH

Layne