Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / August 2005

Tip: Looking for answers? Try searching our database.

Class.cast(Object) - what benefit?

Thread view: 
Ian Pilcher - 20 Aug 2005 17:54 GMT
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!

Signature

========================================================================
Ian Pilcher                                        i.pilcher@comcast.net
========================================================================

Raymond DeCampo - 20 Aug 2005 21:42 GMT
> 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

Signature

XML is the programmer's duct tape.

Roedy Green - 21 Aug 2005 03:59 GMT
>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.
Patricia Shanahan - 21 Aug 2005 04:48 GMT
>>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
Raymond DeCampo - 21 Aug 2005 16:21 GMT
>>> But I can't figure out what benefit it provides.  Can anyone come up
>>> with a usage scenario?
[quoted text clipped - 10 lines]
>
> 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

Signature

XML is the programmer's duct tape.

Thomas Hawtin - 22 Aug 2005 01:09 GMT
> The scenario I am imagining is that you have a generic class
> parametrized by class T.  Somewhere in this class you have an Object
[quoted text clipped - 4 lines]
> 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
Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Raymond DeCampo - 22 Aug 2005 02:43 GMT
>> The scenario I am imagining is that you have a generic class
>> parametrized by class T.  Somewhere in this class you have an Object
[quoted text clipped - 7 lines]
> 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

Signature

XML is the programmer's duct tape.

Roedy Green - 22 Aug 2005 17:47 GMT
>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.


Thomas Weidenfeller - 22 Aug 2005 12:43 GMT
> 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
Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/

Ian Pilcher - 22 Aug 2005 14:56 GMT
> 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(...)

Signature

========================================================================
Ian Pilcher                                        i.pilcher@comcast.net
========================================================================

John C. Bollinger - 23 Aug 2005 05:23 GMT
> 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.

Signature

John Bollinger
jobollin@indiana.edu

Ingo R. Homann - 23 Aug 2005 09:41 GMT
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 - 23 Aug 2005 10:58 GMT
> Hi,
>
[quoted text clipped - 3 lines]
> 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
Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Ingo R. Homann - 23 Aug 2005 12:12 GMT
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!
>
> Oh no you don't!

Well, now, then how do you call it?

Ciao,
Ingo
Thomas Hawtin - 23 Aug 2005 13:32 GMT
>>>>     public <S> S getElement(Class<S> clazz, int i) {
>>>
[quoted text clipped - 5 lines]
>
> Well, now, then how do you call it?

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

Tom Hawtin
Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Ingo R. Homann - 23 Aug 2005 14:50 GMT
Hi,

>>>>>     public <S> S getElement(Class<S> clazz, int i) {
>>>>              ^^^                   ^^^
[quoted text clipped - 8 lines]
>     }
> }

Eh, I think it must be

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

to get no warning.

Ciao,
Ingo
Thomas Hawtin - 23 Aug 2005 15:39 GMT
> 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
Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Ingo R. Homann - 23 Aug 2005 16:07 GMT
Hi,

>> Eh, I think it must be
>>
[quoted text clipped - 6 lines]
> 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 - 23 Aug 2005 22:19 GMT
> 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.

Signature

========================================================================
Ian Pilcher                                        i.pilcher@comcast.net
========================================================================



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.