Re: Collections.class methods anachronisms?
- From: Joshua Cranmer <Pidgeot18@xxxxxxxxxxxxxxxx>
- Date: Tue, 29 May 2007 21:40:53 GMT
jupiter wrote:
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<String> foo = 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.
.
- Follow-Ups:
- Re: Collections.class methods anachronisms?
- From: jupiter
- Re: Collections.class methods anachronisms?
- References:
- Collections.class methods anachronisms?
- From: jupiter
- Collections.class methods anachronisms?
- Prev by Date: Re: Generics references
- Next by Date: Re: Collections.class methods anachronisms?
- Previous by thread: Collections.class methods anachronisms?
- Next by thread: Re: Collections.class methods anachronisms?
- Index(es):
Relevant Pages
|
|
