cannot resolve symbol: Linux

[Jack Gold]

Hello, I am trying to compile three java classes, each in their own file. The files are:

SharedCounter.java
CounterThread.java
CoordinatedThreadDemo.java
(code below)

When I try to compile CounterThread which contains a SharedCounter, I get:

CounterThread.java:5: cannot resolve symbol
symbol : constructor SharedCounter (int)
location: class SharedCounter
private static SharedCounter sharedCounter = new SharedCounter(1);

OK, so I searched through the forum and have tried to set my CLASSPATH variable to cwd. I am using .csh so syntax is
[#]setenv CLASSPATH .

I have also tried using the -classpath switch
[#]javac -classpath . *.java

I have also tried: . ./ ./. etc. . .

Neither of these work!!! I have searched java.sun.com and have gotten mixed reports on the need to set CLASSPATH. I have also searched this forum which has much simple advice on setting the classpath or windows, however the unix equivalent is not working.


Any help appreciated. I understand the classpath is where javac looks for class files. Why is this difficult!?



class SharedCounter {
private int sharedNumber ;

public SharedCounter( int sharedNumber ) {
this.sharedNumber = sharedNumber ;
}

public synchronized void printThenIncrement
( int otherNumber ) {
while ( otherNumber != sharedNumber ) {
try {
wait() ;
} catch ( InterruptedException ie ) {
}
}

System.out.println( sharedNumber ) ;
sharedNumber++ ;

notifyAll() ;
}
}

class CounterThread extends Thread {
private int myNumber ;
private static SharedCounter sharedCounter =
new SharedCounter( 1 ) ;

public CounterThread( int myNumber ) {
this.myNumber = myNumber ;
}

public void run() {
sharedCounter.printThenIncrement( myNumber ) ;
}
}

public class CoordinatedThreadDemo{
public static void main( String [] args ) {
for ( int c = 5 ; c >= 1 ; c-- ) {
CounterThread ct = new CounterThread( c ) ;
ct.start() ;
}
}
}

[Marilyn de Queiroz]

class SharedCounter {
    private int sharedNumber ;
 
    public SharedCounter( int sharedNumber ) {
        this.sharedNumber = sharedNumber ;
    }
 
    public synchronized void printThenIncrement
          ( int otherNumber ) {
        while ( otherNumber != sharedNumber ) {
            try {
              wait() ;
            } catch ( InterruptedException ie ) {
            }
        }
 
        System.out.println( sharedNumber ) ;
        sharedNumber++ ;
 
        notifyAll() ;
    }
}
 
class CounterThread extends Thread {
    private int myNumber ;
    private static SharedCounter sharedCounter =
        new SharedCounter( 1 ) ;
 
    public CounterThread( int myNumber ) {
        this.myNumber = myNumber ;
    }
 
    public void run() {
        sharedCounter.printThenIncrement( myNumber ) ;
    }
}
 
public class CoordinatedThreadDemo{
    public static void main( String [] args ) {
        for ( int c = 5 ; c >= 1 ; c-- ) {
            CounterThread ct = new CounterThread( c ) ;
            ct.start() ;
        }
    }
}

Are these three classes all in the same directory?

"I understand the classpath is where javac looks for class files."

Not exactly. The PATH is where javac looks for source (i.e. *.java) files. The CLASSPATH is where java looks for the *.class files that javac created.

I think your PATH must be set correctly because otherwise you would get an error when you typed "javac".

I put all 3 of your classes in the same directory and compiled them with no problem. I also ran them with no errors.
[ February 04, 2005: Message edited by: Marilyn de Queiroz ]

[Jack Gold]

Thanks for the sanity check, but all are in the same directory. I can compile the first class but then get the cannot resolve symbol.

My $PATH is set correctly, its just the CLASSPATH must not be. What/how did you set your classpath?

[Marilyn de Queiroz]

When I was first setting up my Java stuff on Linux, I found this page very helpful.

I keep all my source files in ~/Java, so my CLASSPATH is set to "~/Java:."

I don't see any package statements in your code, but wanted to double check that you are not using packages in any of these files, because if you were, that would change things.

After you compile the first class, where is the *.class file? Is it in the same directory that you are sitting in? In other words, if your source file is ~/Java/MySource.java and you cd to ~/Java and run %javac MySource.java , is the MySource.class file in the ~/Java directory? Can you see both the MySource.java file and the MySource.class file there?
[ February 05, 2005: Message edited by: Marilyn de Queiroz ]

[Jack Gold]

There are no package statements.

Everything is being done in the CWD. The .java source files and .class files are created in the same directory that I am compiling from/to.

The $PATH variable obviously includes the location of the compiler, and according to you, CLASSPATH is only used at runtime to locate class files.

Is there an equivalent to LD_LIBRARY_PATH in java?

Perhaps the default behaviour of locating *.class files in CWD during compile is being overriden somehow?? Maybe I need to define a compiler switch that explicitly lists classes used?? Does it require the bytecode or just the source files to compile?

I will read the page you supplied. Any other insights appreciated. I verified that the filenames match class names so that doesnt seem to be the problem. Maybe this is a shell configuration issue. I'm woring from .csh.

Thanks,
Chris

[Marilyn de Queiroz]

Is there an equivalent to LD_LIBRARY_PATH in java?

I don't know what LD_LIBRARY_PATH is.

Perhaps the default behaviour of locating *.class files in CWD during compile is being overriden somehow??

Unlikely.

Maybe I need to define a compiler switch that explicitly lists classes used??

Perhaps javac -verbose would give us more info.

Does it require the bytecode or just the source files to compile?

javac compiles the .java source files into bytecode .class files.

I may have oversimplified the CLASSPATH vs PATH issue, but since all of your .java and .class (the ones that exist) are in the same directory, and the compiler compiles some but not all of them, I believe it is an issue other than your CLASSPATH at fault.

Maybe this is a shell configuration issue. I'm woring from .csh.

I never had this problem when I compiled in a .csh shell.

The only other thing I noticed that might be an issue is that the constructor of SharedCounter is public, but the class is not. Again, it doesn't seem that it would matter whether or not the class is public since they are all in the same (default) package, but I'm running out of ideas.

We also have a forum that is devoted to Linux (further down the main page). If we can't resolve it in this forum, perhaps someone that hangs out in that forum might have a suggestion.

[M Beck]

for reference, in Unix, LD_LIBRARY_PATH is how the dynamic linker finds shared libraries (Unix' equivalent of DLLs) needed by running binaries. the Java equivalent would be the CLASSPATH, i believe.

[Ernest Friedman-Hill]

Note that the error message says that the constructor is not found, not that the class is not found. My recommendation is to unset your classpath, delete all .class files in your current directory, and try again.

unsetenv CLASSPATH
rm *.class
javac *.java

[David Harkness]

It's definitely not a classpath issue or the compiler would complain about the symbol SharedCounter. It doesn't; instead it says that the constructor taking a single int doesn't exist. As an aside, javac most definitely does use the CLASSPATH to find other compiled classes, like Log4j, Struts, Hibernate, etc.

Like Marilyn, I suspect a javac bug and the non-publicness of SharedCounter, but for the same reason: I can't think of anything else. And I would think it would complain that you are declaring a SC before it complained about the constructor.

Retype the file from scratch as a last resort. Try a simpler example of two classes with constructors and nothing else.

[Jim Yingst]

[MdQ]: Not exactly. The PATH is where javac looks for source (i.e. *.java) files. The CLASSPATH is where java looks for the *.class files that javac created.

No. The CLASSPATH is used by both commands, java and javac. The java command uses CLASSPATH to look for .class files, or for .jar files which contain .class files. The javac command looks for .class or .java files, or .jar files contianing .class or .java files. Yes, javac looks for .class files - that's how it finds definitions for all the other classes that might be referenced by your program.

The PATH is used by the operating system, not by java or javac. It's how your OS knows where to find commands like java and javac. If your PATH is set incorrectly, then when you type "java Foo" you get a message like "'java' is not recognized as an internal or external command,
operable program or batch file" or "java: command not found".

C: I think EFH has it right - you've got an old SharedCounter.class file somewhere.

[David]: It's definitely not a classpath issue or the compiler would complain about the symbol SharedCounter.

Not quite. The classpath definitely points to a SharedCounter.class file, somewhere. However it's not necessarily the one C is expecting. EFH suggests unsetting CLASSPATH to be sure it's not pointeing to any other directories which contain old versions of SharedCounter.class. Alternately, don't unset it - instead do an echo $CLASSPATH and find out where exactly it's pointing to. Go through the list, and find which of those directories has old classes that you don't need. The java command will alsways use the first valid definition it finds in the classpath - so it's important to pay attention to your entire classpath, and what order it's in.

[David Harkness]

[Me]: It's definitely not a classpath issue or the compiler would complain about the symbol SharedCounter.

[JY]: Not quite. The classpath definitely points to a SharedCounter.class file, somewhere.

But first Mahood tried with "setenv CLASSPATH ." and then with "javac -classpath . *.java". In the latter case, isn't CLASSPATH ignored entirely? In both cases, then, SharedCounter.class -- if it exists -- is being pulled from the current directory, the same directory where SharedCounter.java is and is being compiled.

Would the following steps cause this problem?

Create SharedCounter.java without (int) constructor

Compile it

Copy SharedCounter.class to /tmp

Add (int) constructor to SharedCounter.java

Recompile it

Copy old SharedCounter.class from /tmp to .

At this point, won't telling javac to compile SharedCounter.java see that the source file is not newer than the class file and not recompile it? I doubt Mahood did this, but hey, who knows?

[Layne Lund]

Originally posted by Marilyn de Queiroz:
[QB"I understand the classpath is where javac looks for class files."

Not exactly. The PATH is where javac looks for source (i.e. *.java) files. The CLASSPATH is where java looks for the *.class files that javac created.[/QB]

This still isn't quite correct. The operating system uses PATH to find executable programs. Java does not use the path at all, as far as I know. Typically javac must be told explicitly where to find source files. If you give javac a relative path (such as just a file name), then javac resolves it relative to the current directory.

Layne

edit:

Doh, it looks like I should read the whole thread. Jim beat me to it.
[ February 05, 2005: Message edited by: Layne Lund ]

[Marilyn de Queiroz]

I stand corrected. Thanks, guys.