Java Class.cast() vs. cast operator
Solution 1:
I've only ever used Class.cast(Object)
to avoid warnings in "generics land". I often see methods doing things like this:
@SuppressWarnings("unchecked")
<T> T doSomething() {
Object o;
// snip
return (T) o;
}
It's often best to replace it by:
<T> T doSomething(Class<T> cls) {
Object o;
// snip
return cls.cast(o);
}
That's the only use case for Class.cast(Object)
I've ever come across.
Regarding compiler warnings: I suspect that Class.cast(Object)
isn't special to the compiler. It could be optimized when used statically (i.e. Foo.class.cast(o)
rather than cls.cast(o)
) but I've never seen anybody using it - which makes the effort of building this optimization into the compiler somewhat worthless.
Solution 2:
First, you are strongly discouraged to do almost any cast, so you should limit it as much as possible! You lose the benefits of Java's compile-time strongly-typed features.
In any case, Class.cast()
should be used mainly when you retrieve the Class
token via reflection. It's more idiomatic to write
MyObject myObject = (MyObject) object
rather than
MyObject myObject = MyObject.class.cast(object)
EDIT: Errors at compile time
Over all, Java performs cast checks at run time only. However, the compiler can issue an error if it can prove that such casts can never succeed (e.g. cast a class to another class that's not a supertype and cast a final class type to class/interface that's not in its type hierarchy). Here since Foo
and Bar
are classes that aren't in each other hierarchy, the cast can never succeed.
Solution 3:
It's always problematic and often misleading to try and translate constructs and concepts between languages. Casting is no exception. Particularly because Java is a dynamic language and C++ is somewhat different.
All casting in Java, no matter how you do it, is done at runtime. Type information is held at runtime. C++ is a bit more of a mix. You can cast a struct in C++ to another and it's merely a reinterpretation of the bytes that represent those structs. Java doesn't work that way.
Also generics in Java and C++ are vastly different. Don't concern yourself overly with how you do C++ things in Java. You need to learn how to do things the Java way.
Solution 4:
Class.cast()
is rarely ever used in Java code. If it is used then usually with types that are only known at runtime (i.e. via their respective Class
objects and by some type parameter). It is only really useful in code that uses generics (that's also the reason it wasn't introduced earlier).
It is not similar to reinterpret_cast
, because it will not allow you to break the type system at runtime any more than a normal cast does (i.e. you can break generic type parameters, but can't break "real" types).
The evils of the C-style cast operator generally don't apply to Java. The Java code that looks like a C-style cast is most similar to a dynamic_cast<>()
with a reference type in Java (remember: Java has runtime type information).
Generally comparing the C++ casting operators with Java casting is pretty hard since in Java you can only ever cast reference and no conversion ever happens to objects (only primitive values can be converted using this syntax).