Re: extends "cannot be resolved to a type"
Oliver Wong wrote:
Did you try compiling the files while ensuring that the current
directory be ~ben/docs/comp/lang/java/ ? Did you ensure that "." (the
current directory) is part of the CLASSPATH environment variable?
Ben Collver wrote:
Yes to the former, no to the latter. Adding "." to the CLASSPATH
environment variable fixes my problem on the Linux box.
My main system has no CLASSPATH environment variable. Since it has no
problem, I guess its Java has a built-in class path with "."
Java has no "built-in class path", but your Windows box might.
Generally it is better to script (preferably with Ant) the classpath, invoking
the -cp (-classpath) option to the 'java' command, rather than to use the
CLASSPATH envar. CLASSPATH is global and inflexible, whereas "-cp" is
particular and adaptable.
Also, it is a Bad Thing to use the "default package" for classes.
Better is to use a (possibly fictional) domain, for example "lewscanon.com",
invert the top- and second-level domains and add your package name, like this:
com.lewscanon.example.package
which in most filesystems for most class loaders would correspond to the
relative path
com/lewscanon/example/package/
in which your Foo class bytecode would appear as
com/lewscanon/example/package/Foo.class
"Relative to what?" you ask? Great question - relative to the first classpath
element that has such a subdirectory.
These matters are covered in Sun's tutorial.
-- Lew