• 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

Reg.Cast and instanceof

 
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Read the following expl. for instanceof operator ( from Khalid book )
The compile time check determines whether a reference of <source type> and a
reference of <destination type> can denote object of a class ( or its subclasses )
where this class is a common subtype of both the <source type> and <destination type>
in the inheritance hierarchy.

I am not clear about the lines marked in bold.
Let me all put forward my doubts in an example form

Now whenever we do such a cast as above,
i suppose the RHS should be interpreted as sup instanceof Sub ( that is whether sup is an instance of Sub or its subclasses)
In this case NO as the actual type is of class Super so it will give ClassCastException
I want to clear out few things :
1. Whenever we encounter such casts how should be solve them ( I usually
check the actual type of object, then ask whether it an instance of the class specified in the cast )

2. In what circumstances will the cast give a compile time error
eg :
( String ) sup will give compile time error and they are unrelated
All i want to know in form of steps to be taken while solving such cast related code.
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Whenever you encounter a cast operator you need to think first as the compiler would do, and secod as the "interpreter"
a) The JLS 5.5 tell us when the compiler will complain facing a cast operation. In most of cases both types are clases, then the compiler approves the cast if both types are hieraquically related or are the same. Hieraquically related means one is the superclass or subclass of the other. So far we are considering only the type of the variable and the type within "()".
b) the JVM will complain if the type of the object is not the same or a subclass as the one inside the cast operator "()"
This is why we say Java is a type safe language. We can only send the messages (methods) to an object that are declared in its class or superclasses (supertypes in fact), otherwise an object could receive a message for which it is no prepared to respond.
 
Ranch Hand
Posts: 3141
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Angela,
When casting, you need to keep a few things in mind.
First, the compiler always uses the declared type of both objects.
Second, a superclass can hold a reference to any of it's subclasses.
In your example, you are casting a 'Super' object 'sup' to a valid subclass of 'Super'. The compiler does not see this as an error since it's possible 'sup' may actually hold a reference to an object of it's subclass, 'Sub'.
Note that while we can see, by reading the code, that this is not the case, the compiler doesn't. It just knows it's possible the cast is legal and assumes you know what you are doing
At runtime it turns out that the real type of 'sup' is 'Super'. While a 'Sub' is also a 'Super', a 'Super' is not the same as a 'Sub' so the cast is rejected.
A subclass is, by definition, an extension of a superclass. It contains everything it's superclass does plus more. Which is why you can always assign a subclass to a superclass reference. The reverse is not true. A superclass will be missing the 'more' that's defined in the subclass and will therefore not behave the same as the declared type. It would break the subclass contract.
Hope that helps.

------------------
Jane Griscti
Sun Certified Programmer for the Java� 2 Platform
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic