• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Explanation on import statement behavior?

 
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
this is a follow-up of this
thread.
To sum up, there are two classes Bar and Bartest. Bartest uses Bar, which does not lie in the same package. Bartest thus makes an import og the class.
When the statement is
import com.peter.foo.Bar it compiles
When the statement is
import com.peter.foo.* it does not compile, the error message being
Bartest.java:4: cannot resolve symbol
symbol : constructor Bar ()
This may be explained by the location of the .java and .class files, but I do not have a good explanation.
W.
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are you doubly sure that you don't import any other "Bar" classes inadvertently through importing any other packages?
I've had wierd stuff like this happen up to and including Java 1.3.1, but 1.4 seems a lot more picky about imports.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Make sure there is no other old Bar.class file lying around. If it's complaining about the constructor Bar() but not the class itself, that seems to imply that it's found a Bar class somewhere, but that Bar class does not have a Bar() constructor.
For more info, try this:
 
Wilfried LAURENT
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim,
I have checked, but there I have only one instance of the java file and one instance of the class file.
I also found the error message quite strange. I does not state that it does not find the class, but that the constructor does not exist. But it is the same files!
Franck, may be I should try to compile with jdk1.4, I am currently using jdk1.3.
W.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do the timestamps show that the .class file is newer than the .java file? Delete the class file and recompile to be sure. In fact, delete the class file and temporarily move the java file somewhere else, then compile to verify that there really isn't any other class definition anywhere. Have you made any jar files? If this still doesn't solve it, what do you see when you print Bar.class.getPackage()? Is it the package you expect Bar to be in?
 
Wilfried LAURENT
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well in fact, what I have seen now, is that when I type
javac -classpath "D:\jdk1.3\demo\packages Bar.java
Bar.class is generated in the directory "D:\jdk1.3\demo\demo"
If I add an output directory (the same as the classpath) in the command line, that is
javac -d "D:\jdk1.3\demo\packages" -classpath "D:\jdk1.3\demo\packages Bar.java
then Bar.class is generated in the directory "D:\jdk1.3\demo\demo\com\peter\foo".
It appears that in the first case, the subdirectories are not created. I did not know the influence of the -d options on the subdirectory/package mapping. Is this something that is known?
So it seems that adding the output path in the command line solves the pb. But the error messages remains mysterious. It does not tell us, it has not found the class (I had once such a message - bad class file: d:\jdk1.3\demo\demo\Bar.class
class file contains wrong class: com.peter.foo.Bar
Please remove or make sure it appears in the correct subdirectory of the classpath.-) but this is not the case here. The class is found, but it stumble on the constructor - which explicitely exists-. Is this a situation the java compiler handles not correctly?
W.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic