Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>

On Fri, 04 Apr 2008 16:43:45 -0400, Zig <none@xxxxxxxxxxx> wrote:

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?

-Zig
.