Connecting Tech Pros Worldwide Forums | Help | Site Map

Collections.class methods anachronisms?

jupiter
Guest
 
Posts: n/a
#1: May 28 '07
The Collections class is supposed to, among other things, return
type safe collections from existing collections with static methods
such as .checkedList().

My question is: What is so special about these static methods since
we can do the same thing by declaring the original list generically
with a type like <String>? I mean, once you create the list with
<String the compiler will no longer allow you to add, say,
Integer to the list. So what purpose does .checkedList() provide
in that context?

Maybe it's all about backward compatibility?



Joshua Cranmer
Guest
 
Posts: n/a
#2: May 29 '07

re: Collections.class methods anachronisms?


jupiter wrote:
Quote:
The Collections class is supposed to, among other things, return
type safe collections from existing collections with static methods
such as .checkedList().
>
My question is: What is so special about these static methods since
we can do the same thing by declaring the original list generically
with a type like <String>? I mean, once you create the list with
<String the compiler will no longer allow you to add, say,
Integer to the list. So what purpose does .checkedList() provide
in that context?
>
Maybe it's all about backward compatibility?
>
>
For the most part (where "most part" includes all of the collections
interface), all of the type constraints of generics are only checked at
compile time. The type-safe methods, e.g., checkedList, are guarantees
at /runtime/, something which generics can't do. Observe:

ArrayList<Stringfoo = new ArrayList();
List bar = foo;
bar.add(5);
String s = foo.get(0).substring(4);

This passes the compiler (although the compiler does give a warning), so
the code will be compiled to bytecode where it promptly emits a
ClassCastException. Passing the list through to checkedList still gives
an error, but it is emitted at the point of modification as opposed to
the point of access (which, in some cases, might not even give an error!).

In short, it is mostly a backwards-compatible feature, but it is
desirable in circumstances, so it is in no way an anachronism.
jupiter
Guest
 
Posts: n/a
#3: May 30 '07

re: Collections.class methods anachronisms?



"Joshua Cranmer" <Pidgeot18@epenguin.zzn.comwrote in message
news:F517i.6680$3B1.1920@trnddc08...
Quote:
jupiter wrote:
Quote:
>The Collections class is supposed to, among other things,
>return type safe collections from existing collections with
>static methods such as .checkedList().
>>
>My question is: What is so special about these static methods
>since we can do the same thing by declaring the original list
>generically with a type like <String>? I mean, once you create
>the list with <String the compiler will no longer allow you to
>add, say, Integer to the list. So what purpose does
>.checkedList() provide in that context?
>>
>Maybe it's all about backward compatibility?
>
For the most part (where "most part" includes all of the
collections interface), all of the type constraints of generics
are only checked at compile time. The type-safe methods, e.g.,
checkedList, are guarantees at /runtime/, something which
generics can't do. Observe:
>
ArrayList<Stringfoo = new ArrayList();
List bar = foo;
bar.add(5);
String s = foo.get(0).substring(4);
>
This passes the compiler (although the compiler does give a
warning), so the code will be compiled to bytecode where it
promptly emits a ClassCastException. Passing the list through to
checkedList still gives an error, but it is emitted at the point
of modification as opposed to the point of access (which, in some
cases, might not even give an error!).
>
In short, it is mostly a backwards-compatible feature, but it is
desirable in circumstances, so it is in no way an anachronism.
Great example, Joshua. Thanks.

I guess I was stuck thinking "compiler means everything now" but
when using references to do implicit casting, anything can happen
at runtime as you've clearly shown.



ITMozart
Guest
 
Posts: n/a
#4: Jul 2 '07

re: Collections.class methods anachronisms?


jupiter wrote:
Quote:
Quote:
>This passes the compiler (although the compiler does give a
>warning), so the code will be compiled to bytecode where it
>promptly emits a ClassCastException. Passing the list through to
>checkedList still gives an error, but it is emitted at the point
>of modification as opposed to the point of access (which, in some
>cases, might not even give an error!).
I guess I was stuck thinking "compiler means everything now" but
when using references to do implicit casting, anything can happen
at runtime as you've clearly shown.
This is true, but don't underestimate compiler warnings.

im
Closed Thread