Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>
- From: Zig <none@xxxxxxxxxxx>
- Date: Fri, 04 Apr 2008 16:43:45 -0400
On Fri, 04 Apr 2008 13:16:47 -0400, Owen Jacobson <angrybaldguy@xxxxxxxxx> wrote:
On Apr 4, 12:14 pm, Rakesh <rakesh.use...@xxxxxxxxx> wrote:I was curious if there is a reason why java.util.Properties extends
from HashMap<Object, Object> instead of HashMap<String, String>
(seems more intuitive to me).
A variation of that would be -
how do we get about converting Properties to Map<String, String> .
Backwards compatability. In Java 1.4 and earlier,
Properties.get(Object) returned Object; changing that signature for
1.5 would break any code that used that method without an immediate
cast to String.
-o
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
.
- Follow-Ups:
- References:
- Prev by Date: Re: pass by reference
- Next by Date: Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>
- Previous by thread: Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>
- Next by thread: Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>
- Index(es):
Relevant Pages
|
