Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 400
  • Last Modified:

Cannot resolve symbol symbol : variable

Hi,

I'm having trouble compiling a class; it's tripping up on a call to a static method in another class in the package.  The error is:

.\src\com\mycompany\myproject\Document.java:105: cannot resolve symbol
symbol  : variable Libraries
location: class com.mycompany.myproject.Document
                return Libraries.getShortName2(library);

Libraries.class is in .\class\com\mycompany\myproject\, along with the previous compile of Document.class and the rest of the package class files.

I'm confused because what I had originally done was this: download the .java files AND the .class files (that had been compiled elsewhere) and then try to compile myself.  This was apparently successful, at least the modified date on the all of the .class files was updated.  I then modified the Document class (not Libraries, nor the call to Libraries in Document) and now I can't recompile.  What's going on?  I'm sure it's something simple but I'm new to this.

Thanks

0
madacebo
Asked:
madacebo
  • 12
  • 10
  • 8
  • +3
4 Solutions
 
zzynxSoftware engineerCommented:
Do you have an import for that Libraries class
0
 
zzynxSoftware engineerCommented:
I mean in the Document class source file
0
 
TimYatesCommented:
is the source file for "Libraries.java" in your source folder with Document.java?

how are you compiling the class?
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
zzynxSoftware engineerCommented:
>> is the source file for "Libraries.java" in your source folder with Document.java?
If not you have to import it:

import com.something.dir1.Libraries;
0
 
madaceboAuthor Commented:
- The Libraries class isn't imported, it's in the same package.
- Yes, Libraries.java is in the same folder as Document.java.
- I'm compiling with the command "javac -g:none -verbose -deprecation -classpath .\class -d .\class .\src\com\mycompany\myproject\Document.java" on Win2K, j2sdk1.4.2_07
0
 
TimYatesCommented:
is

  cd src
  javac -verbose -deprecation -classpath ..\class -d ..\class com\mycompany\myproject\Document.java

any better?
0
 
kupra1Commented:
You need to set your classpath for that folder. Set the classpath either by using
set classpath=%classpath%;.\class; (name of the parent package directory which contains the class files).

Also, change the compilation directory to the parent directory of the package. e.g. as TimYates correctly pointed out. Change the directory to src and compile from there.

Once you set this, you can compile from anywhere by giving the absolute path.
0
 
madaceboAuthor Commented:
Sorry, I should have included my classpath before, it was:

.;C:\somedirs\Java\class;C:\somedirs\Java\class\rowset.jar

To confirm file locations, source files for the package are:
C:\somedirs\Java\src\com\mycompany\myproject\*.java

Class files are:
C:\somedirs\Java\class\com\mycompany\myproject\*.class

So I added .\class to the classpath, as well as C:\somedirs\Java\class\com\mycompany\myproject (kupra1, this is what I took you to mean by "name of the parent package directory which contains the class files") and ran the command from the src dir as specified in TimYates' comment, but I get the same error.
0
 
zzynxSoftware engineerCommented:
And so, getShortName2() is a static method of the class Libraries?
Can you post the Document.java code? (And mark the line that produces the error?)
0
 
madaceboAuthor Commented:
Here's the call to getShortName2 in Document.java:

public String getLibraryName() {
     return Libraries.getShortName2(library);
}

Would it really help to post the whole file?  It contains no other references to Libraries and so far no other errors.
Here's the called function from Libraries.java:

static String getShortName2(int lib) {
     return shortNames[lib];
}
0
 
zzynxSoftware engineerCommented:
>> Would it really help to post the whole file?
Mmmm. Maybe not.

I just wonder why you get:
cannot resolve symbol
symbol  : variable Libraries

I would expect something like: cannot find class Libraries.

Strange that the compiler consider it as a variable
...
0
 
madaceboAuthor Commented:
I thought that was odd as well.  The problem seems simple; these classes just aren't seeing the other classes in the package.  When I try to recompile any of the classes in this package I get similar errors.  The .class files all start with the same package declaration (package com.mycompany.myproject;).  Should the compiler output show the other package classes loading?  Or display something else that shows it knows that the other classes in the package are there?
0
 
zzynxSoftware engineerCommented:
>> The .class files all start with the same package declaration (package com.mycompany.myproject;).
You probably mean the .java files
>> Should the compiler output show the other package classes loading?
No.

You could always try to
- make a copy of the content of Libraries.java to ZZLibraries.java
- replace all occurrences of "Libraries" with "ZZLibraries"
- In your Document.java file replace "Libraries" into "ZZLibraries"
- Same problem?
0
 
madaceboAuthor Commented:
Yes, I mean the .java files.
Yes, same problem.
0
 
zzynxSoftware engineerCommented:
>>>> Should the compiler output show the other package classes loading?
>>No.
Sorry. Maybe the answer is yes due to the -verbose option you use. (Never used it)


All right, it must be a path problem...

What about:

cd src
javac -verbose -deprecation -classpath C:/somedirs/Java/class -d C:/somedirs/Java/class c:/somedirs/Java/src/com/mycompany/myproject/Document.java
0
 
objectsCommented:
add C:\somedirs\Java\src to your classpath

or compile the classes from C:\somedirs\Java\src\com\mycompany\myproject
0
 
kupra1Commented:
You added it incorrectly.

>>>> So I added .\class to the classpath, as well as C:\somedirs\Java\class\com\mycompany\myproject

It should be only
C:\somedirs\Java\class

Thanks
0
 
kupra1Commented:
The concept is that the ClassLoader will go to the classes directory and then look into the package name defined by the import statement and hence, will traverse the directory tree down from there. So, by adding C:\somedirs\Java\class\com\mycompany\myproject to the classpath and then having the import statements will enforce the classloader to look for a class file located at C:\somedirs\Java\class\com\mycompany\myproject\com\mycompany\myproject\*.class which won't be available and hence, the "can't resolve symbol" exception.

Do let me know if you have any question.
0
 
madaceboAuthor Commented:
kupra1: C:\somedirs\Java\class was in my classpath from the beginning (see comment 03/01/2005 11:40AM PST). Also, you mention "the package name defined by the import statement"; I don't have an import statement for the package, just the package declaration itself.

objects: I added C:\somedirs\Java\src, same error.  Is the compiler looking for the .java files or the .class files?  Also tried compiling from C:\somedirs\Java\src\com\mycompany\myproject, same error.

zzynx: Tried compiling from the src directory with absolute paths, as you suggest, same error.

classpath is currently
.;C:\somedirs\Java\class;C:\somedirs\Java\class\rowset.jar;C:\somedirs\Java\src
0
 
objectsCommented:
what command are you currently using
0
 
madaceboAuthor Commented:
javac -verbose -deprecation -classpath C:\somedirs\Java\class -d C:\somedirs\Java\class (path depending on the directory i'm trying to compile from)\Document.java
0
 
objectsCommented:
> -classpath C:\somedirs\Java\class

remove that (it ovverrides the classpath setting).
0
 
madaceboAuthor Commented:
Same error.  I don't think it's a classpath problem, since the compiler is successfully loading two imported classes from the same hierarchy (one of them is com.mycompany.utility.Spanish, and Spanish.class is located in C:\somedirs\Java\class\com\mycompany\utility\).  It's only having trouble with classes in its own package.  
0
 
madaceboAuthor Commented:
I say classES because when I to compile any of the other classes in the package I get the same behavior- errors on any reference to another class in the package.  If there are none, it compiles fine.
0
 
objectsCommented:
are all the classes declared to be in the correct package?
0
 
kupra1Commented:
Madacebo,
Try to compile with this if you dont have the package statement in your classes:
javac -verbose -deprecation -classpath C:\somedirs\Java\class\com\package\myproject -d C:\somedirs\Java\class\com\package\myproject (path depending on the directory i'm trying to compile from)\Document.java
instead of
javac -verbose -deprecation -classpath C:\somedirs\Java\class -d C:\somedirs\Java\class (path depending on the directory i'm trying to compile from)\Document.java

If you have the package statement(package com.package.myproject;) in your classes, then you can compile with your statement .
javac -verbose -deprecation -classpath C:\somedirs\Java\class -d C:\somedirs\Java\class (path depending on the directory i'm trying to compile from)\Document.java

0
 
madaceboAuthor Commented:
The first line of all 14 class files in the package is (and has been from the beginning)
package com.mycompany.myproject;

kupra1, why do you say it should be
package com.package.myproject;  ?
0
 
kupra1Commented:
ohh.. Sorry, I mistyped it. You are correct. It should be
package com.mycompany.myproject;

Just to reconfirm the fact that the classes are being generated and placed at the right location, delete all the old class files and then recompile them. Also, since you are compiling the classes individually, first compile the independent classes and then the dependent classes.
0
 
madaceboAuthor Commented:
Yes, tried that.  Four out of 14 compile (in the right spot).  The rest fail on references to other classes in the package, including references to the 4 that compiled, after they compiled.  Thanks for your help so far.
0
 
kupra1Commented:
ok... great. Atleast we moved a little further. I presume that the classes compiled are the independent classes. Since you said that the classes are being in the right spot, I again presume that they are put in the folder C:\somedirs\Java\class\com\mycompany\myproject and you are setting the classpath to C:\somedirs\Java\class.

e.g.
cd C:\somedirs\Java\src
javac -verbose -deprecation -classpath C:\somedirs\Java\class -d C:\somedirs\Java\class com/mycompany/myproject/Libraries.java

javac -verbose -deprecation -classpath C:\somedirs\Java\class -d C:\somedirs\Java\class com/mycompany/myproject/Document.java

Thanks
0
 
madaceboAuthor Commented:
That is correct, except that I compile from C:\somedirs\Java\ with the command
javac -verbose -deprecation -classpath .\class -d .\class .\src\com\mycompany\myproject\Document.java

The reason for this is that the person who originally wrote the code and decided on the directory structure compiles that way.  Since I know it works for him, that's the method I'm trying for.
0
 
kupra1Commented:
madacebo,
 it works for me. do one thing. delete all your old class files and compile once more starting with the independent classes(e.g. Libraries.java) and then moving to dependent classes (Document.java). After you compile Libraries.java, reconfirm where is the class file i.e. in which directory. Is it in C:\somedirs\Java\class\com\mycompany\myproject\ folder?
Thanks
0
 
objectsCommented:
> javac -verbose -deprecation -classpath .\class -d .\class .\src\com\mycompany\myproject\Document.java

try:

javac -verbose -deprecation -classpath .\class;.\src -d .\class .\src\com\mycompany\myproject\Document.java

> Since I know it works for him, that's the method I'm trying for.

Then ask him what the problem is :)
0
 
zzynxSoftware engineerCommented:
Since it seems we weren't able to help at all, I would recommend a delete with refund.
0
 
VenabiliCommented:
No way to be a refund... as the Asker forgot to answer to the last suggestions..
0
 
zzynxSoftware engineerCommented:
Right, right. A delete wihout refund then.
0
 
kupra1Commented:
I would suggest splitting the points among the participants.
0
 
zzynxSoftware engineerCommented:
thanks madacebo
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 12
  • 10
  • 8
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now