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

On Fri, 04 Apr 2008 13:16:47 -0400, Owen Jacobson
<angrybaldguy@gmail.com> wrote:


I don't think this is the reason. Particularly, making a method
signature generic does not change it's runtime signature.

Even if Properties were made as "Properties extends HashMap<String,String>"
Properties.get will inherit the Map.get signature, which is just:

java/util/Map.get(Ljava/lang/Object;)Ljava/lang/Object;

and thus runtime compatibility is preserved. At the compiler's option,
additional synthetic bridge methods may be created in order to support
covariant return types, but even then, a method with a Ljava/lang/Object
return type must exist at runtime.

Additionally, the parameter "key" of Map.get is not generified: all Maps
accept java.lang.Object as a key, under the premis that if you pass in a
different type then it can't possibly have a previous mapping.

Thus code calling "Properties.get(new Object())" would still be
compatible at compile time.

Lastly, all Strings are assignable as Objects. Thus code calling "Object
x=Properties.get(key)" will also still be compile-time compatible.

I think the real reason Properties does not extend
Hashtable<String,String> is that, while discouraged, it is still valid
to have Properties with non-string key/values. An existing Java 1.4 API
could something like:

public Properties createProps() {
    Properties props=new Properties();
    props.setProperty("name", "foo");
    props.put("version", new Integer());
    return props;
}

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>, and users would be "locked in" to using Java
1.4 as long as they continued to use this API.

HTH,

-Zig