«

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

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

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

"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