Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Class.cast(Object) - what benefit?

Reply
Thread Tools

Class.cast(Object) - what benefit?

 
 
Ian Pilcher
Guest
Posts: n/a
 
      08-20-2005
I just noticed it at:

http://java.sun.com/j2se/1.5.0/docs/...va.lang.Object)

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

Thanks!

--
================================================== ======================
Ian Pilcher http://www.velocityreviews.com/forums/(E-Mail Removed)
================================================== ======================
 
Reply With Quote
 
 
 
 
Raymond DeCampo
Guest
Posts: n/a
 
      08-20-2005
Ian Pilcher wrote:
> I just noticed it at:
>
> http://java.sun.com/j2se/1.5.0/docs/...va.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

--
XML is the programmer's duct tape.
 
Reply With Quote
 
 
 
 
Raymond DeCampo
Guest
Posts: n/a
 
      08-21-2005
Patricia Shanahan wrote:
> Roedy Green wrote:
>
>> On Sat, 20 Aug 2005 11:54:42 -0500, Ian Pilcher
>> <(E-Mail Removed)> wrote or quoted :
>>
>>
>>> But I can't figure out what benefit it provides. Can anyone come up
>>> with a usage scenario?

>>
>>
>>
>> Perhaps it is just shorthand for checking if the object is of the
>> right class and if not throwing an exception.
>>

>
> 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

--
XML is the programmer's duct tape.
 
Reply With Quote
 
Thomas Hawtin
Guest
Posts: n/a
 
      08-22-2005
Raymond DeCampo wrote:
>
> 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
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
 
Reply With Quote
 
Raymond DeCampo
Guest
Posts: n/a
 
      08-22-2005
Thomas Hawtin wrote:
> Raymond DeCampo wrote:
>
>>
>> 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>.


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.)

This whole Class<T> thing doesn't sit well with me somehow. It helps
for some reason to remember that generics are implemented via erasure.

> 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

--
XML is the programmer's duct tape.
 
Reply With Quote
 
Thomas Weidenfeller
Guest
Posts: n/a
 
      08-22-2005
Ian Pilcher wrote:
> I just noticed it at:
>
> http://java.sun.com/j2se/1.5.0/docs/...va.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/Generic...ms.html#FAQ602

in Angelika Langer's generics FAQ.

/Thomas
--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/...g/java/gui/faq
http://www.uni-giessen.de/faq/archiv....java.gui.faq/
 
Reply With Quote
 
Ian Pilcher
Guest
Posts: n/a
 
      08-22-2005
Thomas Weidenfeller wrote:
>
> See
>
> http://www.langer.camelot.de/Generic...ms.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(...)

--
================================================== ======================
Ian Pilcher (E-Mail Removed)
================================================== ======================
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      08-22-2005
On Mon, 22 Aug 2005 01:09:15 +0100, Thomas Hawtin
<(E-Mail Removed)> wrote or quoted :

>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.


 
Reply With Quote
 
John C. Bollinger
Guest
Posts: n/a
 
      08-23-2005
Ian Pilcher wrote:
> 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.

--
John Bollinger
(E-Mail Removed)
 
Reply With Quote
 
Ingo R. Homann
Guest
Posts: n/a
 
      08-23-2005
Hi,

John C. Bollinger wrote:
> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments