File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes determining class of an obj at compile and runtime Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "determining class of an obj at compile and runtime" Watch "determining class of an obj at compile and runtime" New topic
Author

determining class of an obj at compile and runtime

Stephen Huey
Ranch Hand

Joined: Jul 15, 2003
Posts: 618
My understanding is that the VM will determine the class of an object on a case by case basis at runtime as long as the possible classes are in the same inheritance path. However, my understanding of this is pretty shaky, and I'm trying to get clear on when either at compile time or at runtime it will not be possible to use what I may think is polymorphism. In other words, when might the compiler or VM not call the method for the particular class that I want? E.g. what's an example of when a method for the superclass might get called when I'm intending it to be for a subclass? Hope this is clear enough for you--all I know is that my head is pretty murky on it.
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
One example would be if the method was static since static methods are not polymorphic.
------------
Just to correct your wording. The runtime will determine the type of an object. If that type can not be stored in the reference variable you are trying to place it in then you get an exception.
For example:
Object b = new JButton();
String s = (String)b;
This will compile but will fail at runtime because b is not a String.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
If a method is declared static or private, overriding is not allowed.
Otherwise, overriding may occur.
----
We do not need to know the following, but I want to show you all possible cases for completeness.
At compile-time, the compiler evaluates a method invocation and associates an �invocation mode�:

The invocation mode, computed as follows:
1. If the compile-time declaration has the static modifier, then the invocation mode isstatic.
2. Otherwise, if the compile-time declaration has the private modifier, then the invocation mode is nonvirtual.
3. Otherwise, if the part of the method invocation before the left parenthesis is of the form super . Identifier or of the form ClassName.super.Identifier then the invocation mode is super.
4. Otherwise, if the compile-time declaration is in an interface, then the invocation mode is interface.
5. Otherwise, the invocation mode is virtual.

If the invocation mode is static, overriding is not allowed. If the invocation mode is nonvirtual, overriding is not allowed. Otherwise, the invocation mode is interface, virtual, or super, and overriding may occur.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: determining class of an obj at compile and runtime