Re: Properties2 extends Hashmap, pros and cons?

Discussion in 'Java' started by Jon Skeet, Jul 5, 2003.

  1. Jon Skeet

    Jon Skeet Guest

    NoName NoName <NoMail@nomail..com> wrote:
    > Current core Properties class is extended from Hashtable. Hastable is a
    > synchronized keyvalue container from Java1 era.
    >
    > Do you see here any use of "Properties2 extends Hashmap" implementation.
    > What pros and/or cons. Should Java2 has a properties-like class using Java2
    > collection implementation?


    It should have an implementation of Properties which doesn't implement
    Map at all. Making Properties extend Hashtable was a mistake to start
    with.

    --
    Jon Skeet - <>
    http://www.pobox.com/~skeet/
    If replying to the group, please do not mail me too
     
    Jon Skeet, Jul 5, 2003
    #1
    1. Advertising

  2. >>Current core Properties class is extended from Hashtable. Hastable is a
    >>synchronized keyvalue container from Java1 era.
    >>
    >>Do you see here any use of "Properties2 extends Hashmap" implementation.
    >>What pros and/or cons. Should Java2 has a properties-like class using Java2
    >>collection implementation?

    >
    > It should have an implementation of Properties which doesn't implement
    > Map at all. Making Properties extend Hashtable was a mistake to start
    > with.


    Hmm..interesting. Would you share your thoughts more in detail. Im
    planning to create own namevalue class for taylored use.

    What I dont like most with current Properties is .load/.save methods not
    supporting UTF-8 format. Its quite hard to write config files with Win2k
    Notepad 'cause unicodes should use \uXXXX escaped format.
     
    X_AWieminer_X, Jul 5, 2003
    #2
    1. Advertising

  3. >> What I dont like most with current Properties is .load/.save methods
    >> not supporting UTF-8 format. Its quite hard to write config files with
    >> Win2k Notepad 'cause unicodes should use \uXXXX escaped format.
    >>

    > Have you tried using native2ascii


    Yep, but its not an enduser tool anyway. Users edit textfiles with
    Notepad and/or Word and files should go easy to Java application,
    sometimes changes should be reloaded at runtime.
     
    X_AWieminer_X, Jul 6, 2003
    #3
  4. Jon Skeet

    Chris Smith Guest

    X_AWieminer_X wrote:
    > >>Current core Properties class is extended from Hashtable. Hastable is a
    > >>synchronized keyvalue container from Java1 era.
    > >>
    > >>Do you see here any use of "Properties2 extends Hashmap" implementation.
    > >>What pros and/or cons. Should Java2 has a properties-like class using Java2
    > >>collection implementation?

    > >
    > > It should have an implementation of Properties which doesn't implement
    > > Map at all. Making Properties extend Hashtable was a mistake to start
    > > with.

    >
    > Hmm..interesting. Would you share your thoughts more in detail. Im
    > planning to create own namevalue class for taylored use.


    I can't speak for Jon, but I can explain why I think it was a mistake to
    have Properties extend Hashtable. It's because a Hashtable is a more
    general-purpose kind of data structure that's suitable in more places
    than a Properties. For example, Properties requires that names and
    values be Strings, whereas with Hashtable they can be any Object.
    However, because Properties extends Hashtable, you can get around that
    requirement with a back door that allows the user to break the general
    contract of the Properties class.

    Even if that were fixed (for example, by overriding the Hashtable put
    and get methods to throw exceptions if the arguments aren't Strings), a
    Properties object would still be useful only in a limited set of
    circumstances compared to a Hashtable... which violates the general
    principle of substitutability (sometimes called Liskov substitutability,
    after someone who stated it clearly). That means that you could
    conceivable have a reference of type Hashtable (which points to a
    Properties object), and it would be inherently broken to give it to a
    method that is supposed to operate on all Hashtable objects.

    My guess is that this design decision was made by someone who was still
    stuck in the "fascinated-by-inheritance" phase of OO understanding.

    > What I dont like most with current Properties is .load/.save methods not
    > supporting UTF-8 format. Its quite hard to write config files with Win2k
    > Notepad 'cause unicodes should use \uXXXX escaped format.


    Which, of course, has little to do with its being derived from
    Hashtable.

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Jul 6, 2003
    #4
  5. Jon Skeet

    xarax Guest

    Chris Smith <> wrote in message news:<>...
    /snip/
    > My guess is that this design decision was made by someone who was still
    > stuck in the "fascinated-by-inheritance" phase of OO understanding.

    /snip/

    You're probably exactly right about that. The implementor saw
    some apparent similarities and decided to reuse the code. A better
    approach would have been to design an interface for Properties
    and an abstract implementation AbstractProperties that internally
    used a Hashtable object (thus getting the code reusability he
    wanted in the first place). A factory class would dispense
    objects that implement the Properties interface that would
    protect client code from becoming dependent upon the actual
    implementation details.

    Other languages, like Eiffel, would allow a private inheritance
    of a Hashtable implementation so that client code could not
    up-cast the object and use it like a Hashtable. However, that's
    not the case for Java, so object composition would have been
    a better choice than inheritance.
     
    xarax, Jul 6, 2003
    #5
  6. Jon Skeet

    Dale King Guest

    "Chris Smith" <> wrote in message
    news:...
    > X_AWieminer_X wrote:
    > > >>Current core Properties class is extended from Hashtable. Hastable is

    a
    > > >>synchronized keyvalue container from Java1 era.
    > > >>
    > > >>Do you see here any use of "Properties2 extends Hashmap"

    implementation.
    > > >>What pros and/or cons. Should Java2 has a properties-like class using

    Java2
    > > >>collection implementation?
    > > >
    > > > It should have an implementation of Properties which doesn't implement
    > > > Map at all. Making Properties extend Hashtable was a mistake to start
    > > > with.

    > >
    > > Hmm..interesting. Would you share your thoughts more in detail. Im
    > > planning to create own namevalue class for taylored use.

    >
    > I can't speak for Jon, but I can explain why I think it was a mistake to
    > have Properties extend Hashtable. It's because a Hashtable is a more
    > general-purpose kind of data structure that's suitable in more places
    > than a Properties. For example, Properties requires that names and
    > values be Strings, whereas with Hashtable they can be any Object.
    > However, because Properties extends Hashtable, you can get around that
    > requirement with a back door that allows the user to break the general
    > contract of the Properties class.



    I can't speak for Jon either, but since I have spoken on this issue several
    times in the past...

    The other issue is that you are stuck with the semantics of Hashtable,
    synchronized and unordered, with no duplicate entries. You can't keep the
    properties in the same order they were in the file or sorted by key as you
    could with LinkedHashMap and TreeMap.

    The correct way to do it is that you should use containment, not
    inheritance. This is one of the prime examples why containment should be
    favored over inheritance.

    So instead of extending Hashtable you would maintain a reference to a Map
    implementation:

    class Properties implements Map
    // in JDK1.5 you might have this implement Map<String,String>
    {
    private final Map map;
    public Properties( Map map )
    {
    this.map = map;
    }
    public Properties()
    {
    this( new HashMap() );
    }

    // Most of the Map methods delegate to the contained map

    // Plus other methods specific to Properties.
    }

    This lets you substitute any implementation of Map.
    --
    Dale King
     
    Dale King, Jul 8, 2003
    #6
    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. Kumar Vijay Mishra

    PSL pros and cons

    Kumar Vijay Mishra, Sep 29, 2004, in forum: VHDL
    Replies:
    2
    Views:
    2,599
    vhdlcohen
    Oct 2, 2004
  2. Benny
    Replies:
    1
    Views:
    435
    Paul Wistrand
    Mar 1, 2004
  3. J.S.
    Replies:
    10
    Views:
    6,087
    shawpnendu
    May 20, 2009
  4. Randall Parker

    Pros and cons for using https on a logon page?

    Randall Parker, Dec 4, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    762
    nimd4
    May 17, 2014
  5. Maric Michaud

    threading and multicores, pros and cons

    Maric Michaud, Feb 14, 2007, in forum: Python
    Replies:
    24
    Views:
    1,157
    Paul Boddie
    Feb 20, 2007
Loading...

Share This Page