Am i missing something here?

[k Oyedeji]

Hi
I have the following set of classes:
Vehicle which had a boolean variable which is set to false
when declared
A class car which extends vehicle
a main method in another class in the same package which
creates an array of vehicles and assigns car objects to the vehicle
now when i try to call some of the (public) vehicle methods or reference the fields when looping over the array i get an noSuchMethod error for methods and a similar one when i try to reference the fields.
As the array is an array of vehicles does this not mean that i should be able to reference vehicle methods even though i created the objects like:

 myVehicles[0] = new car(...) 

As i say all fields are public and methods.
Can anyone spot any reason why this should not work?
Thanks

[Tom Hill]

i assume youve got: Vehicle[] myVehicles = new Vehicle[b]
where int b is the number of Vehicles you want to do stuff to. Remember that Arrays cannot change size after they have been instantiated. I would use an ArrayList to store Objects of unknown quantities.

[k Oyedeji]

That is almost correct i have
Vehicle myVehicles[] = new Vehicle[4];
which i think is more or less the same

[Ernest Friedman-Hill]

I started to write a mini-introduction to polymorphism, but I think, on re-reading your message, that your problem is just that you've got some incompatible changes among the classes in your application. Recompile all of your classes, and see if that doesn't clear things up. It looks like you're getting runtime errors of a sort which are essentially impossible to get unless some of the classes changed without dependent classes being recompiled. Very likely, if you try to recompile you'll get compiler errors, but hopefully these will be easier to understand.

[k Oyedeji]

Hi
I cleaned out all the classes and recompiled and i still get the same error. I definetly have a public boolean member called isHired
when i loop over the array and try and reference this field i get a noSuchField exception. Even in JBuilder the intelisense picks up and displays the field in the Vehicle class. Could the fact that i have assigned car objects to a Vehicle array be a problem? I dont think it should be as car *is* a vehicle.
Could the way the classes are compiled have any bearing on this?

Thanks

[Ilja Preuss]

I agree with Ernest - if those errors happen at runtime, something got terribly wrong. It simply can't happen if the classes got compiled together. You should probably check your classpath settings...

[Tiberiu Paun]

If you say that all your classes have been compiled successfully in the same time, let me know if I am right:
U have a packge, lets call it mypack, where u have those classes.
U execute the command java mypack.MainClass, or simply MainClass, if u don't have it in the package.
Please look to see if u have any of the classes from the package in the current directory (where u execute java command), while java will look for classes in the . (if it is first in classpath), and then in jars or directories.
If u do have any classes named as the ones from the package in the directory mentioned above, just remove them, and try again.
Best regards, Tibi.

[k Oyedeji]

Hi
Thanks for your suggestions but still no luck
My classpath:
C:\javatemp
My directory structure:
C:\javatemp\rental
*every* class has the line package renatl at the top. This should be correct. I am running the main method of the main class (also in the package) as java rental.RentalCentre
I cant think of anything else that could be wrong!
THanks

[k Oyedeji]

Perhaps it would help if i posted some code?

[Ernest Friedman-Hill]

You could post some code, but it would have to be pretty convoluted to produce these symptoms. Far more likely is that you've got different versions of one or the other of these classes somewhere on your classpath at runtime, but perhaps not at compile time.

[k Oyedeji]

Ernest and others
Thank you, thank you , thank you very much. Ernest's comments got me thinking if another version of the class files was being picked up as i did have a few other versions floating around in my directory structure, this is what i had:

C:\javatemp\rental  - contained the most recent source files and is the directory i am runnig the appication from

but i also had

C:\javatemp\rental\bak - contained previous versions of source and class files

and then

C:\javatemp\rental\rental - contained previous version of package including source files and class files

I think its the last one which caused the problem And this raises some interesting questions, what happens when you have a package with the same name inside a package with the same name as i'm assuming this would mean that both folders contained classes which are now on the class path. However as i am starting my application by using
javac rental.RentalCentre
How is it that classes which are not in this package (but a sub package) can be used at run time. Furhtermore surely the classes inside
C:\javatemp\rental\rental
should be in the package rental.rental and not visible?
Finally all the classes in
C:\javatemp\rental\rental - still have package rental on the first line -
but this does not match the directory structure (as only C:\javatemp is on the classpath). I imagine they would not compile again but they were compiled before being moved. Is there no runtime check?
Oh well, it works now but i think i'm even more confused and would love to know what exactly was going on. Perhaps i should move this to the intermmeidiate forum?
Kola

[Dirk Schreckmann]

I think the short answer to your questions is that you might want to play around with Java packages and CLASSPATH settings a bit more.
If a class is declared to be in rental and it resides in the C:\javatemp\rental\rental folder, Java can use it if the CLASSPATH setting somehow specified C:\javatemp\rental as part of its value.
If you've included the current working directory as part of the CLASSPATH value, and the current working directory is C:\javatemp\rental, then classes in the rental package that reside in the C:\javatemp\rental\rental folder are fair game.