Jim Redman wrote:
> I'd be opposed to any changes that require Java2. I'm also not sure
> why the change is proposed. Is there some pressing reason to drop the
> Hashtable?
Hashtable and Vector are concrete classes, not interfaces.
As of JDK 1.2 they are synchronized implementations of the
Map and List interfaces, respectively. The synchronization
mechanism adds overhead that is unnecessary in many XML-RPC
settings. This performance hit is minor, however; the real
objection to these concrete classes is that they appear as
argument and return types in service interfaces, which makes
these services less flexible, both to implement and to use.
For example, if I have a service defined by this interface,
interface MyService {
Vector getDates ();
}
and I want to implement this service using a third-party class
(that I can't change) that looks like this,
class TheirServiceImpl /* does not implement MyService */ {
public Date[] getDates () { ... }
}
then my service impl will have to copy the returned array
into a Vector.
class MyServiceImpl implements MyService {
private TheirServiceImpl theirServiceImpl = ...;
public Vector getDates () {
Date[] dates = theirServiceImpl.getDates();
Vector result = new Vector(dates.length);
for (int i = 0; i < dates.length; ++i) {
result.addElement(dates[i]);
}
return result;
}
}
If org.apache.xmlrpc worked in terms of Lists intead of Vectors,
I would have
interface MyService {
List getDates ();
}
class MyServiceImpl implements MyService {
TheirServiceImpl theirServiceImpl = ...;
public List getDates () {
return Arrays.asList(theirServiceImpl.getDates());
}
}
which does _not_ copy the returned Date array. Same thing goes
on the client side when passing in Hashtable or Vector arguments.
You may respond that copying arguments and return values is no
big deal, but it is. In one application I worked on, there was
a method that returned a snapshot of system state, which could
be huge. When the server returned this value the entire structure
had to be copied from its original form and rebuilt as nested
Hashtables and Vectors. If Maps and Lists were used, the entire
structure could have been used without any copying, using Map
and List adapters. Forcing the use of the conrete classes slowed
things down significantly.
I'm not denying that your need to keep 1.1 compatibility carries
a lot of weight. I'm just saying that wanting to use Maps and
Lists in org.apache.xmlrpc is not frivolous.
There is a 1.1 collections compatibility jar from Sun. Would
that do the trick for your 1.1 user base?
--tim
