java.util.Properties extending from HashMap<Object, Object> insteadof HashMap<String, String>

Discussion in 'Java' started by Rakesh, Apr 4, 2008.

  1. Rakesh

    Rakesh Guest

    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> .
    Rakesh, Apr 4, 2008
    #1
    1. Advertising

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

    On Apr 4, 12:14 pm, Rakesh <> 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
    Owen Jacobson, Apr 4, 2008
    #2
    1. Advertising

  3. Rakesh

    Rakesh Guest

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

    On Apr 4, 1:16 pm, Owen Jacobson <> wrote:
    > On Apr 4, 12:14 pm, Rakesh <> 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


    Thanks Owen.

    From JDK 1.5 onwards - how do I cast Properties to Map<String,
    String>

    (One obvious answer is to - use the methods - propertyNames() to get
    the Enumeration and then use getProperty() to get the property value
    and insert it into a new Map).

    I was curious if there is any other O(1) way of doing this (like
    casting etc.).
    Rakesh, Apr 4, 2008
    #3
  4. Rakesh

    Roedy Green Guest

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

    On Fri, 4 Apr 2008 09:14:53 -0700 (PDT), Rakesh
    <> wrote, quoted or indirectly quoted someone
    who said :

    >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).


    Properties predates generics.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Apr 4, 2008
    #4
  5. Rakesh

    Roedy Green Guest

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

    On Fri, 4 Apr 2008 11:03:44 -0700 (PDT), Rakesh
    <> wrote, quoted or indirectly quoted someone
    who said :

    >From JDK 1.5 onwards - how do I cast Properties to Map<String,
    >String>
    >
    >(One obvious answer is to - use the methods - propertyNames() to get
    >the Enumeration and then use getProperty() to get the property value
    >and insert it into a new Map).
    >
    >I was curious if there is any other O(1) way of doing this (like
    >casting etc.).


    In general this is a nasty problem in Java. If something is
    effectively declared <Object> or Object[] the JVM can't trust you that
    all the elements are really something more specific. You have to fish
    them out one, lets the cast mechanism check them, and put them into a
    more specific container.

    It is not as painful as operation as you might first think. You are
    not moving any objects around, just copying 32-bit references. With a
    new Map, though you are rebuilding the lookup structure.

    If you want to cheat, there may be a way of using type erasure, to
    write something with serialisation, then read it back with a more
    specific type.

    Another approach would be to extend the old class to be generic, using
    the original to do the heavy lifting, or write a custom version that
    assumes strings, and does the casts for you.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Apr 4, 2008
    #5
  6. Zig wrote:
    > On Fri, 04 Apr 2008 13:16:47 -0400, Owen Jacobson
    > <> wrote:
    >
    >> On Apr 4, 12:14 pm, Rakesh <> 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


    The thing I don't understand is why, before 1.5, Properties extended
    anything other than Object. Extending Hashtable or HashMap before
    generics created features, such as the ability to add a mapping from an
    Integer to a Float, that make no sense for Properties.

    Patricia
    Patricia Shanahan, Apr 4, 2008
    #6
  7. Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>

    Patricia Shanahan wrote:

    >
    > The thing I don't understand is why, before 1.5, Properties extended
    > anything other than Object. Extending Hashtable or HashMap before
    > generics created features, such as the ability to add a mapping from
    > an Integer to a Float, that make no sense for Properties.


    Presumably someone took a shortcut wthout thinking the consequences
    through. It happens :)
    Mike Schilling, Apr 5, 2008
    #7
  8. Re: java.util.Properties extending from HashMap<Object, Object>instead of HashMap<String, String>

    Patricia Shanahan <> writes:

    > The thing I don't understand is why, before 1.5, Properties extended
    > anything other than Object. Extending Hashtable or HashMap before
    > generics created features, such as the ability to add a mapping from an
    > Integer to a Float, that make no sense for Properties.


    Plain bad judgement. "It seemed like a good idea at the time". Joshua
    Bloch has said as much in his "Effective Java Language Programming
    Guide".

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Apr 5, 2008
    #8
  9. Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>

    Zig wrote:
    > On Fri, 04 Apr 2008 20:02:29 -0400, Lew <> 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.


    I think this is axiomatic. If an API is intended to be used for A,
    the documentation explains carefully that it's intended for A, and all
    the examples show it being used for A, some perverse bastard is going
    to use it for B, C, and D, particularly when that's inferior to the
    natural ways of doing those.
    Mike Schilling, Apr 6, 2008
    #9
  10. Re: java.util.Properties extending from HashMap<Object, Object>instead of HashMap<String, String>

    Lew <> writes:

    > Actually, you show a way to abuse Properties. You aren't supposed to use 'put()':


    This is what shows that the inheriting from Hashtable is a modelling
    error. Properties definitly doesn't satisfy 'is-a Hashtable'.

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Apr 7, 2008
    #10
  11. Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>

    Lasse Reichstein Nielsen wrote:
    > Lew <> writes:
    >
    >> Actually, you show a way to abuse Properties. You aren't supposed
    >> to use 'put()':

    >
    > This is what shows that the inheriting from Hashtable is a modelling
    > error. Properties definitly doesn't satisfy 'is-a Hashtable'.


    Exactly. Properties may *have* a Hashtable (it was the obvious way to
    implement it), but it isn't a Hashtable.
    Mike Schilling, Apr 8, 2008
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kannan
    Replies:
    0
    Views:
    533
    Kannan
    Mar 11, 2005
  2. Hendrik Maryns

    Extending java.util.Set

    Hendrik Maryns, Feb 15, 2006, in forum: Java
    Replies:
    11
    Views:
    5,253
    Mike Schilling
    Feb 17, 2006
  3. Spendius
    Replies:
    0
    Views:
    1,910
    Spendius
    May 20, 2008
  4. Lorenzo
    Replies:
    0
    Views:
    1,380
    Lorenzo
    Dec 11, 2009
  5. Blue®
    Replies:
    10
    Views:
    289
    Thomas 'PointedEars' Lahn
    May 27, 2005
Loading...

Share This Page