Consider this:
Map<Integer, String> map =new HashMap<Integer, String>();
...
String token = map.get("bogus" );
The compiler does not complain about "bogus" being a string rather than the required Integer. I am amazed I have not noticed this issue until now. It seems the compiler can and should get cranky when it encounters this.
> Consider this:
>
> Map<Integer, String> map = new HashMap<Integer,
> String>();
> ...
> String token = map.get( "bogus" );
>
> The compiler does not complain about "bogus" being a
> string rather than the required Integer. I am amazed
> I have not noticed this issue until now. It seems the
> compiler can and should get cranky when it encounters
> this.
You are not modifying the map so the operation is perfectly typesafe.
This has been brought up many times. The delcaration for get() takes an Object. In short, it's incorrect for Map to enforce the behavior you expect. It would require casting Objects to String in order to see if they are keys in the map. It's possible to have an Object reference that points to a String that is in the Map. If the API only allowed gets on Strings it would force this monstrosity:
if (o instanceof String) {
out = map.get((String) o);
}
Mutation and type safety are entirely independent concepts. The compiler knows nothing about the distinction between a "get" and a "set" operation. You're argument is specious. What's going on here is the class designer decided not to use a generic type on the getter. That means I get bugs that could have been exposed at compile time.
Now, on balance, it's the right choice because you have always been able to query a map with any old object and simply get a null back. So I am OK with that. As for having to type cast to enforce: false. The compiler would complain loudly had the get method accepted a generic type and you failed to provide it.
> Mutation and type safety are entirely independent
> concepts. The compiler knows nothing about the
> distinction between a "get" and a "set" operation.
Yeah? What does that have to do with what I wrote?
> You're argument is specious. What's going on here is
> the class designer decided not to use a generic type
> on the getter. That means I get bugs that could have
> been exposed at compile time.
That's what I said. They chose to do that because it's the correct choice.
> Now, on balance, it's the right choice because you
> have always been able to query a map with any old
> object and simply get a null back. So I am OK with
> that. As for having to type cast to enforce: false.
No it's not, you didn't understand me or you don't understand the concepts.
> The compiler would complain loudly had the get method
> accepted a generic type and you failed to provide it.
That doesn't make any sense.