Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>
- From: Zig <none@xxxxxxxxxxx>
- Date: Sat, 05 Apr 2008 20:11:37 -0400
On Fri, 04 Apr 2008 20:02:29 -0400, Lew <lew@xxxxxxxxxxxxx> wrote:
Completely wrong. Properties is meant for Strings only.
Take a look at the javadocs for Properties.stringPropertyNames(). At first glance, one expects this method to cast keySet() to a Set<String>, but note one difference:
"Properties whose key or value is not of type String are omitted"
There may be some other examples, but this was just the first that caught my eye.
I think this is an indication that, while Properties are *meant* for Strings, there may be existing code which uses them for other things. Current developers using those APIs may need some awareness that, if the Properties has passed through a 3rd party API, the developer is not guaranteed that casting each key or value to a String will be successfull.
It is not intended for use as a Map at all, really.
This seems like a valid answer to the OP's question. I guess Properties has two "defects" if you try to use it as a Map:
* Map functions on a Properties object do no reflect the recursive capabilities of Properties - Properties.getProperty can have more keys available than Map.get, if the Properties was constructed with a default Properties object. But, the javadocs for Properties do not explicitly define whether or not to expect Map functions will reflect the recursive nature.
* The type has to be <Object,Object> due to backwards compatibility issues for APIs which used Properties in ways it was not intended for.
I think it would be useful if Properties were more Map-like. One might initialize some global defaults wrapped in Collections.unmodifiableMap, and use the same reference as the "defaults" when creating child Properties objects. Or compute intersections between different Properties - for a UI where the user had multiple elements selected, you would want to display only keys that both elements had in common (obviously, your intersection method should accept anything assignable to Map, without duplicating the method just to operate on Properties objects). Likewise, a UI or debugger should have the option to drop a loaded Properties object into a TreeMap in order to display keys in sorted form.
Oh well, I guess that's just nit-picking. Maybe Apache Commons Collections will offer some good replacements in the future.
-Zig
.
- Follow-Ups:
- References:
- java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>
- From: Rakesh
- Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>
- From: Owen Jacobson
- Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>
- From: Zig
- Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>
- From: Zig
- Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>
- From: Lew
- java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>
- 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):