Class.cast(Object) - what benefit?

[Ian Pilcher]

I just noticed it at:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#cast(java.lang.Object)

But I can't figure out what benefit it provides. Can anyone come up
with a usage scenario?

Thanks!

 

[Raymond DeCampo]

I just noticed it at:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#cast(java.lang.Object)


But I can't figure out what benefit it provides. Can anyone come up
with a usage scenario?

I think that this is designed to be used with generics. I am not
familiar enough with generics however to provide an example.

Ray

 

[Raymond DeCampo]

I don't think it's that, because, according to the API documentation, it
throws ClassCastException "if the object is not null and is not
assignable to the type T."

It seems more likely to be something to do with generics, but I haven't
worked out what.

Patricia

The scenario I am imagining is that you have a generic class
parametrized by class T. Somewhere in this class you have an Object
that you want to cast to type T. Presumably the syntax

T t = (T)obj;

is illegal. So one would use the Class.cast() method. Although I'm not
sure how you get an instance of Class<T> in this case.

DISCLAIMER: I haven't worked with generics, so the above may be totally
wrong, misguided and generally rot. Also, I may have used the incorrect
vocabulary.

Ray

 

[Thomas Hawtin]

The scenario I am imagining is that you have a generic class
parametrized by class T. Somewhere in this class you have an Object
that you want to cast to type T. Presumably the syntax

T t = (T)obj;

is illegal. So one would use the Class.cast() method. Although I'm not
sure how you get an instance of Class<T> in this case.

When you construct a class with generic parameter T, you can pass in a
Class<T>. You can then do the cast with both static and dynamic
checking, which (T) does not give you. It also doesn't produce unchecked
warnings, because it is checked (at that point).

Tom Hawtin

 

[Raymond DeCampo]

When you construct a class with generic parameter T, you can pass in a
Class<T>.

That seems hokey. I expected a more natural mechanism. (Please do not
misinterpret, you are the messenger, I am criticizing the composer of
the message, so to speak.)

You can then do the cast with both static and dynamic
checking, which (T) does not give you. It also doesn't produce unchecked
warnings, because it is checked (at that point).

Tom Hawtin

Ray

 

[Thomas Weidenfeller]

I just noticed it at:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#cast(java.lang.Object)


But I can't figure out what benefit it provides. Can anyone come up
with a usage scenario?

See

http://www.langer.camelot.de/GenericsFAQ/FAQSections/ProgrammingIdioms.html#FAQ602

in Angelika Langer's generics FAQ.

/Thomas

 

[Ian Pilcher]

See

http://www.langer.camelot.de/GenericsFAQ/FAQSections/ProgrammingIdioms.html#FAQ602

I see it used, but there's no explanation of why it's there. The best
I can figure out, it's just a shortcut for:

if (!cls.isInstance(o))
throw new ClassCastException(...)

 

[Roedy Green]

When you construct a class with generic parameter T, you can pass in a
Class<T>. You can then do the cast with both static and dynamic
checking, which (T) does not give you. It also doesn't produce unchecked
warnings, because it is checked (at that point).

I'll do some decompilation to verify this if someone has not already.


Is there ANY run time code that protects a typed ArrayList from
getting the wrong objects in it? I presume not. It is fully type
erased.

There must be a run-time cast somewhere when you take Objects out of
the typed ArrayList. I presume the compiler inserts these after a get
call. They are part of the calling code, not the ArrayList.

These casts were necessary even if you had 100% confidence they would
always succeed.

 

[John C. Bollinger]

I see it used, but there's no explanation of why it's there. The best
I can figure out, it's just a shortcut for:

if (!cls.isInstance(o))
throw new ClassCastException(...)

No, you're missing the point, which is that the cast can be typechecked
at compile time. More specifically, the cast of an object of generic
type can be typechecked at compile time, making it possible to avoid an
"unchecked cast" warning and *ensure* that no ClassCastException will be
thrown.

Example [Not tested]:

class ListHolder <T> {

private List<T> list;

// ...

public <S> S getElement(Class<S> clazz, int i) {

// Compatibility of S and T checked at compile time,
// on a per-invocation basis:

return clazz.cast(list.get(i));
}
}


Note that two distinct type parameters are involved in my example; I
can't imagine Class.cast() being useful with fewer.

 

[Ingo R. Homann]

Hi,

public <S> S getElement(Class<S> clazz, int i) {

^^^ ^^^
But that means that you have to pass the Type-Parameter (S) twice which
is not a good idea!

And "S.class" doesn't work.

Ciao,
Ingo

 

[Thomas Hawtin]

Hi,


^^^ ^^^
But that means that you have to pass the Type-Parameter (S) twice which
is not a good idea!

Oh no you don't!

And "S.class" doesn't work.

That's why he passed a Class<S>.

Tom Hawtin

 

[Ingo R. Homann]

Hi,

Oh no you don't!

Well, now, then how do you call it?

Ciao,
Ingo

 

[Thomas Hawtin]

Well, now, then how do you call it?

class MyCLass {
String myFunc(ListHolder<CharSequence> listHolder) {
return listHolder.getElement(String.class, 0);
}
}

Tom Hawtin

 

[Ingo R. Homann]

Hi,

class MyCLass {
String myFunc(ListHolder<CharSequence> listHolder) {
return listHolder.getElement(String.class, 0);
}
}

Eh, I think it must be

listHolder.<String>getElement(String.class, 0);

to get no warning.

Ciao,
Ingo

 

[Thomas Hawtin]

Eh, I think it must be

listHolder.<String>getElement(String.class, 0);

to get no warning.

Nope. The type is inferred. Same as with EnumSet.of.

I have tried that exact code on 1.5.0-b64, 1.5.0_04-b05 and
1.6.0-ea-b48. It compiles without a whisper.

Tom Hawtin

 

[Ingo R. Homann]

Hi,

Nope. The type is inferred. Same as with EnumSet.of.

I have tried that exact code on 1.5.0-b64, 1.5.0_04-b05 and
1.6.0-ea-b48. It compiles without a whisper.

I just tried it with Eclipse 3.1 final (which I admit is not such a good
reference-implementation as your different JDKs) and...

....it compiles without a whisper.

Very interesting, I never expected that!

Thanks,
Ingo

 

[Ian Pilcher]

No, you're missing the point, which is that the cast can be typechecked
at compile time. More specifically, the cast of an object of generic
type can be typechecked at compile time, making it possible to avoid an
"unchecked cast" warning and *ensure* that no ClassCastException will be
thrown.

I've tested and enhanced your example a little bit, and I may see the
point, but I surely don't agree with it.

package temp;

import java.util.*;

class ListHolder<T>
{
private List<T> list;

public ListHolder(List<T> list)
{
this.list = list;
}

public <S> S getElementAs(Class<S> cls, int i)
{
return cls.cast(list.get(i)); // no warning
// return (S)(list.get(i)); // warning
}
}

class Cast
{
public static void main(String[] args)
{
List<Integer> list = new LinkedList<Integer>();
list.add(new Integer(0));
ListHolder<Integer> holder = new ListHolder<Integer>(list);

// This is compatible
Object o = holder.getElementAs(Object.class, 0);

// This is not
List l = holder.getElementAs(List.class, 0);
}
}

You're right that the Class.cast form does not throw an "unchecked cast"
warning, and the normal cast does. That seems to be the only
difference, however, and you've provided a perfect example of why this
warning is stupid in the first place.