Let's say you get an object somewhere, and you need to cast it, but you don't know the class to cast to at compile time. That's when you can use Class.cast.
Without the cast, the only thing you could return was Component or Object. That would require some extra casting.
Let's say the method didn't cast, and just returned Component. The calling code would be:
With the cast you don't need to cast it in the calling code.
Another example where the cast is actually necessary. Let's say you want to filter a list to include only objects of a specific class. You still want to keep the destination collection generic though, so you don't want a Collection<Object>.
Without the cast, you cannot get an reference of type T because you don't know T at compile time. Calling "(T)o" is just bad.
Well, the thing is, any object has two different types.
The first one is the declared type, this is the type used when declaring it. In the case of "Object a" that is object. This type determines what methods and fields are available during compile time. You need to cast it to be able to call other methods and fields.
The second type is the actual type. When you initialize an object using "new", this will assign the type behind it as the actual type. This type will never change for as long as the object exists (although you can assign a new object of a different type to the reference variable). This type is used when calling overridden methods, for instance. This is also the type that "getClass" returns.
When you cast your Cat object to an object, all it does is change the declared type. The actual type does not change because your Cat object does not change; the Class.cast method does not change your object in any way. This explains why it print "class Cat": your object "a" may be an Animal or Object in declaration, the object it points to is a Cat. When you then call getClass, it returns the Cat.class object.
Something to think about is the following: why would you want to use getClass to get the declared class of an object? You know this class at compile time; either it is hardcoded (e.g. Object a yields Object.class) or it is retrieved using Class.forName. Either way, there is no need for the runtime retrieval method at compile time.
The last part summarized: you know you've declared the type as Object, then why not use Object.class directly. [ September 08, 2007: Message edited by: Rob Prime ]
Joined: Aug 30, 2007
thanks again! the actual thing i want to do is: I have a javabean and a row of ResultSet.(they have the same fields) I want to evaluate all the fields of the javabean by get the value from ResultSet automaticlly.
but the classes(types) of the bean's fields are unknown until runtime.
i did it just then,method as follow: 1.i used rs.getObject(fieldName) to get the value. 2.cast the value as the same of bean's field. 3.invoke the bean's write method to evaluate the field.
now the program can work with all the classes,and int value. wish it can work prefect will other type~
Originally posted by Rob Prime: Well, the thing is, any object has two different types.
That's not really correct.
Notice that variables of non-primitive types in Java are not objects themselves - they are references to objects. The type of the variable can be different than the type of the actual object that the variable refers to - the object's type can be a subtype of the variable's type. In your example, you can have a variable of which the type is Animal, and it can refer to a Cat object, because Cat is a subclass of Animal.
So the object itself does not have two different types - it's the types of the variable and the object that are different.
For your problem (filling the fields of a Java bean with data from a ResultSet) you do not need this kind of casting at all.
The Java Beans API (see the package java.beans) contains methods to discover what fields a bean has (names, types etc.) and can give you a java.lang.reflect.Method object that you can use to call the setter method of a field in your bean. You don't need to know the data type of the field of the bean to do this; you can just call invoke(...) on the Method object, which accepts Objects as parameters (it will cast those objects automatically for you to what the actual setter method expects).
Note that casting does not magically change the type of an object. Casting only tells the compiler "look, I have this object here, and you should treat is as a ...". At runtime, if the object is not really of the type you are casting it to, you will get a ClassCastException. [ September 08, 2007: Message edited by: Jesper Young ]