Where did javac find some other class?

[Andreas Leitgeb]

My problem is, I get a "cannot resolve symbol" error from javac,
but to all my knowledge and inspection, the class named as
"location" *does* have that symbol (the symbol is a parameterless
public non-static method, in case it matters)

As it seems, the javac finds the .class somewhere else than I
think it does. Is there any trick to let javac not only tell
me the FQN of the class of which it claims that it is lacking
that symbol, but also from where on the classpath it really got
that class from? Something like:
"location: class x.y.Z found in /foo/bar/snafu.jar"

Unfortunately, this is part of some bigger project, and the
classpath is quite large, and I can't just trim the classpath
without having ant/javac bail out somewhere else.

Thanks in advance.

 

[markspace]

As it seems, the javac finds the .class somewhere else than I
think it does. Is there any trick to let javac not only tell
me the FQN of the class of which it claims that it is lacking
that symbol, but also from where on the classpath it really got
that class from? Something like:
"location: class x.y.Z found in /foo/bar/snafu.jar"

-verbose might do it

Unfortunately, this is part of some bigger project, and the
classpath is quite large, and I can't just trim the classpath
without having ant/javac bail out somewhere else.

This is really the problem and something the project as a whole needs to
control. I'd recommend that you ditch the classpath altogether and use
-cp on the command line, setting it appropriately for each step when
javac is invoked. Thus, you don't have to worry about the compiler
getting confused with some other class when compiling your stuff, you
just set the local path you need for your stuff.

You can do this right now, for your own compile task, with the -cp
option. Just set it and the CLASSPATH variable will be ignored, for
that one invocation only.

 

[Andreas Leitgeb]

You could manually gather the classpath as so many Jar files, then use
"unzip -l" to list the files, and grep to locate the class you are
talking about. Assuming that your build system invokes javac as an
external command, then you could make your own wrapper script which
invokes javac, but before that prints out the exact options passed to
javac, including the classpath.

That would have been a feasible way, too, but I found something else
meanwhile: setting the attribute verbose=yes for the javac action in
build.xml reveiled the bad jar file, as it then dumped the real location
of *every* involved class, which of course included the culprit.

Problem solved. Thanks, anyway.

PS: I'm a bit embarrassed that I didn't think of verbose *before*
posting here :-}

 

[Andreas Leitgeb]

-verbose might do it

This is really the problem and something the project as a whole needs to
control. I'd recommend that you ditch the classpath altogether and use
-cp on the command line,

The <javac> action already had an explicit classpath-tag specified, which
was composed of several <path>s, some of which included all *.jar of certain
directories. It was a directory with mostly third party libs and only a
few own jar-files, which also followed some naming pattern. It was of
course one of the other jars that contained own classes despite not
following the naming scheme. Probably it got accidentally restored from
an old backup that was made before that naming scheme for our own jar-files
crystallized.

Just not spectacular enough for a failblog entry...

Thanks.

 

[Roedy Green]

My problem is, I get a "cannot resolve symbol" error from javac,
but to all my knowledge and inspection, the class named as
"location" *does* have that symbol (the symbol is a parameterless
public non-static method, in case it matters)

See
http://mindprod.com/jgloss/compileerrormessages.html#CANNOTFINDSYMBOL

http://mindprod.com/jgloss/compileerrormessages.html#CANNOTRESOLVESYMBOL
--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

 

[Andreas Leitgeb]

See
http://mindprod.com/jgloss/compileerrormessages.html#CANNOTFINDSYMBOL

My problem was already solved (there's already a couple of followup posts).

Anyway I looked at your link, to see if that would have helped - here's
my feedback:
It starts with a definite claim "you used a variable name you did not
define." then follow possible reasons for the undefinedness of
that variable, and only much later follow the other variants of
missing symbols from other classes. Perhaps that should even be
separate major items, as in my eyes an undefined local variable
has a sufficiently different procedure for resolving, than a
symbol (method or constructor) missing from a different class.
"Cannot find symbol ..., means you likely you did ..."
-> "Cannot find symbol ... could mean you did ..."
the paragraph for “Cannot find symbol method" seems to be mostly a copy
of the previous one "Cannot find symbol constructor"
"There is some other synatax error, than ...": than -> that
"Jusing ..." -> "Using ..."

It already did contain the hint for using "-verbose", which in form of
a verose=yes attribute in an ant's build.xml actually made my spot the
problem in my case.

Perhaps you could add one more possible reason explicitly:
- perhaps javac found a wrong version of the referenced class in
a different .jar, that you accidentally have on the classpath.
Use javac's -verbose option and check, if it picked that class
from the expected place.
But I admit, my case probably wasn't all that common.

I hope to have helped the helper