Compile Problem involving Dependencies

[Novice]

I'm having a problem compiling some Java code which I _think_ has to do
with a dependency issue that I don't fully understand. I wonder if someone
here can enlighten me?

I have a class named FooApplet which is defined as public and extends
JApplet. FooApplet makes use of a class I wrote called WrapUtils, which is
simply a public class. WrapUtils in turn makes use of other classes I wrote
called ErrorUtils and CountUtils, both of which are simply public classes.

I'm using Eclipse 3.7 and FooApplet compiles just fine. However, WrapUtils
shows compile errors at every mention of ErrorUtils and CountUtils.
ErrorUtils and CountUtils both compile cleanly.

The suggested fixes for the errors in WrapUtils include generating an
import statement for ErrorUtils and CountUtils, even though they are in the
same package as WrapUtils. When I click on the option to generate those
imports, the import statement is NOT added to WrapUtils and the errors for
ErrorUtils and CountUtils remain. The red "x" remains on WrapUtils both in
the editor and in Package Explorer. Why does Eclipse not see the ErrorUtils
and CountUtils? All of the classes are public and all of WrapUtils,
CountUtils and ErrorUtils are in the same package, although it is a
different package than the one containing FooApplet?

So, to recap, we have:

com.foo.FooApplet (public extends JApplet)
- invokes com.foo.utilities.WrapUtils (public)
- invokes com.foo.utilities.CountUtils (public)
- invokes com.foo.utilities.ErrorUtils (public)

All references to CountUtils and ErrorUtils in WrapUtils are flagged as
compile errors: "CountUtils cannot be resolved".

What stupid mistake am I making? Is this a dependency error? Or is the fact
that the methods in WrapUtils, CountUtils and ErrorUtils are all static
that are the source of the problem?

 

[markspace]

com.foo.FooApplet (public extends JApplet)
- invokes com.foo.utilities.WrapUtils (public)
- invokes com.foo.utilities.CountUtils (public)
- invokes com.foo.utilities.ErrorUtils (public)

This should work, although you have shown any code and don't say how you
"invoke" a class. It's possible that Eclipse is just confused. Try
clean and rebuild, saving all files, checking the file system directly
to make sure it actually matches what you think you are seeing, and
double checking project properties. Don't forget the old "reboot and
see if it works."

Could be a problem with how you are invoking the classes however, or how
you've included other projects or libraries. Best to supply a
compilable example that duplicates the problem if you want the most help.

 

[Martin Gregorie]

I'm having a problem compiling some Java code which I _think_ has to do
with a dependency issue that I don't fully understand. I wonder if
someone here can enlighten me?

I have a class named FooApplet which is defined as public and extends
JApplet. FooApplet makes use of a class I wrote called WrapUtils, which
is simply a public class. WrapUtils in turn makes use of other classes I
wrote called ErrorUtils and CountUtils, both of which are simply public
classes.

I'm using Eclipse 3.7 and FooApplet compiles just fine. However,
WrapUtils shows compile errors at every mention of ErrorUtils and
CountUtils. ErrorUtils and CountUtils both compile cleanly.

The suggested fixes for the errors in WrapUtils include generating an
import statement for ErrorUtils and CountUtils, even though they are in
the same package as WrapUtils. When I click on the option to generate
those imports, the import statement is NOT added to WrapUtils and the
errors for ErrorUtils and CountUtils remain. The red "x" remains on
WrapUtils both in the editor and in Package Explorer. Why does Eclipse
not see the ErrorUtils and CountUtils? All of the classes are public and
all of WrapUtils, CountUtils and ErrorUtils are in the same package,
although it is a different package than the one containing FooApplet?

So, to recap, we have:

com.foo.FooApplet (public extends JApplet)
- invokes com.foo.utilities.WrapUtils (public)
- invokes com.foo.utilities.CountUtils (public)
- invokes com.foo.utilities.ErrorUtils (public)

All references to CountUtils and ErrorUtils in WrapUtils are flagged as
compile errors: "CountUtils cannot be resolved".

What stupid mistake am I making? Is this a dependency error? Or is the
fact that the methods in WrapUtils, CountUtils and ErrorUtils are all
static that are the source of the problem?

You don't mention where the classes are in your directory structure or
the package name of FooApplet. I would assume that, relative to where
Eclipse is run you'd find that

- FooApplet contains the "package com.foo;" declaration

- all three other sources contain the "package com.foo.utilities;"
declaration.

- the path names of the .java files relative to the Eclipse root are:

com/foo/FooApplet.java
com/foo/utilities/WrapUtils.java
com/foo/utilities/CountUtils.java
com/foo/utilities/WrapUtils.java

If your package declarations and relative pathnames differ, thats most
likely the cause.

 

[Novice]

This should work, although you have shown any code and don't say how you
"invoke" a class. It's possible that Eclipse is just confused. Try
clean and rebuild, saving all files, checking the file system directly
to make sure it actually matches what you think you are seeing, and
double checking project properties. Don't forget the old "reboot and
see if it works."

Could be a problem with how you are invoking the classes however, or how
you've included other projects or libraries. Best to supply a
compilable example that duplicates the problem if you want the most help.

Many thanks, markspace! The fresh build did the trick; all the compiler
errors went away and I was able to run the applet successfully. I like
Eclipse but it does seem to get confused sometimes; I should have thought
of the rebuild as a possible solution.

I would have gone to a code example if no one could suggest a solution
without one but you've saved me the bother ;-)

Thanks again!

 

[markspace]

The fresh build did the trick; all the compiler
errors went away and I was able to run the applet successfully. I like
Eclipse but it does seem to get confused sometimes; >

You're welcome. NetBeans seems to have the same problem. Periodically
weird errors show up and I have to do the "clean and rebuild full
project." I guess it might be common behavior related to some compiler
API they both use, since Java has made one available for programmers a
while back.

*shrug* At least you didn't have to reach for the "big red switch."

 

[Lew]

You're welcome. NetBeans seems to have the same problem. Periodically

Pretty much *all* build systems have this problem.

weird errors show up and I have to do the "clean and rebuild full
project." I guess it might be common behavior related to some compiler
API they both use, since Java has made one available for programmers a
while back.

*shrug* At least you didn't have to reach for the "big red switch."

It's common behavior to all build systems, particularly Java-esque ones that track dependencies through the .class files in the "-d" target directory of javac.

In the face of refactoring and certain strange scenarios, .class files remain in the target directory for which either the source files have a changedtransitive dependency or the source no longer exists or a constant is not deemed worthy of a recompile or what-all.

Later another class sees something in the now-no-longer-valid .class file and weirdness ensues. Finally the hapless programmer does a full "clean", and voilà! Problem solved.

 

[Roedy Green]

I'm having a problem compiling some Java code which I _think_ has to do
with a dependency issue it.

The easy way to handle dependency problems to compile everything at
once and let Javac sort it out. You can do this with *.java on the
javac command line or using ANT.

See http://mindprod.com/jgloss/javac.exe
http://mindprod.com/jgloss/ant.html

I have a feeling you also need to read
http://mindprod.com/jgloss/classpath.html
and
http://mindprod.com/jgloss/package.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
It's difficult to be rigorous about whether a machine really knows,
thinks, etc., because we’re hard put to define these things.
We understand human mental processes only slightly better than
a fish understands swimming.
~ John McCarthy (born: 1927-09-04 died: 2011-10-23 at age: 84).
Inventor of the term AI (Artificial Intelligence),
the short-circuit OR operator (|| in Java),
and LISP (LIst Processing Language) that makes EMACS
(Extensible MACro System) so addictive.

 

[Roedy Green]

Pretty much *all* build systems have this problem.

IntelliJ seems to keep very good track. When I export and compile with
ANT, a clean build will help, especially getting rid of obsolete
class files (e.g. for inner classes).
--
Roedy Green Canadian Mind Products
http://mindprod.com
It's difficult to be rigorous about whether a machine really knows,
thinks, etc., because we’re hard put to define these things.
We understand human mental processes only slightly better than
a fish understands swimming.
~ John McCarthy (born: 1927-09-04 died: 2011-10-23 at age: 84).
Inventor of the term AI (Artificial Intelligence),
the short-circuit OR operator (|| in Java),
and LISP (LIst Processing Language) that makes EMACS
(Extensible MACro System) so addictive.