If this method existed, and you were tasked with calling this method
such as:
Integer version=(Integer) createProps().get("version");
This code would likely not compile in Java 5 if properties was made as
Hashtable<String,String>...
As I was thinking about this, it seems I may have been in error. In
theory, a crafty developer could call:
Map<String,String> props=createProps();
Integer version=(Integer) ((Map<String, ?>) props).get("version");
That's nice and obfuscated, but in theory one could still get data out
of a hypothetical Properties<String,String>, which was used for
non-string values in a 3rd party 1.4 API.
I guess the answer might be that, when one implements
Map<String,String>, methods expect to iterate over map.getEntrySet() as
Map.Entry<String,String> without worrying about class cast exceptions.
It is the Java 5 developer's job to create a Hashtable<String, Object>,
when they need to pass a Hashtable to a Java 1.4 method that uses
non-string values.
So perhaps for properties, a type was chosen, so users would not have to
specify it at every use, avoiding things like
Properties<String,String> props=new Properties<String,String>()
but, users iterating over values should still be aware that legacy APIs
could have used properties for things besides String, and developers
would need to make a decision on when to use getProperty(String) vs
get(Object).
Anyway, that's my current best guess. Any takers?
Completely wrong. Properties is meant for Strings only. It is not intended