You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Gus Mueller <gu...@mu.org> on 2002/06/06 22:59:47 UTC
Dictionary vs. Hashtable in XmlRpc.java
I was wondering if anyone saw any problems with using a Dictionary instead
of a Hastable in XmlRpc.java for the function writeObject(Object obj)
My problem is, that when using a Hashtable, the order of the objects put
in are not kept the same (it uses a hash!) so I had created a class that
implements Dictionary (which Hashtable does also) and use that instead.
The result is what I want, and it's works with existing code also.
The diff like this for java/org/apache/xmlrpc/XmlRpc.java
785c785
< else if (obj instanceof Hashtable)
---
> else if (obj instanceof java.util.Dictionary)
788c788
< Hashtable struct = (Hashtable) obj;
---
> java.util.Dictionary struct = (java.util.Dictionary)
obj;
795c795
< write(nextkey);
---
> chardata(nextkey);
and here's the code if it's easier to read for ya:
else if (obj instanceof java.util.Dictionary)
{
startElement("struct");
java.util.Dictionary struct = (java.util.Dictionary) obj;
for (Enumeration e = struct.keys(); e.hasMoreElements(); )
{
String nextkey = (String) e.nextElement();
Object nextval = struct.get(nextkey);
startElement("member");
startElement("name");
chardata(nextkey);
endElement("name");
writeObject(nextval);
endElement("member");
}
endElement("struct");
}
Does anyone see any problems with this code? Should it be applied to the
original XmlRpc.java so other folks could possibly benifit?
thanks,
-gus
--
"Christmas means carnage!" -- Ferdinand, the duck
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
On 2002.06.08 07:50 John Wilson wrote:
>
> > System.getProperty
> >
> > also always throws and prints in IE so that causes more problems in
> > applets.
>
> Jim,
>
> Would explicitly catching the exception help?
I'm working from memory, but my recollection is that it prints an
exception in the IE Java console (== tech support call) regardless of
whether you catch it or not.
>
> It's possible that using java.util.Map, etc. screws JDK 1.x applets
> anyway.
> I seem to remember that applet jar/zip files could not contain java.*
> classes because of security issues. In which case packaging a subset
> of the
> Java 2 Collections classes with the applet would not work.
There are a couple of places where the change seems to make little
sense except for consistency, for example, Vector->ArrayList in
WebServer.
Looking through the patch, the following occurs to me. You've already
created the AggregateFactory class, would it be possible to create:
interface MapInterface {
put
get
}
interface ListInterface {
add
get
}
(OR whatever). Then return a concrete implementation from
AggregateFactory. In 1.1 the implementation is a trivial subclass of a
Hashtable and Vector. In Java2, Map and List. Then the
AggregateFactory could be switched to change implementations.
I don't, however, have a good suggestion for Iterators and Enumerations.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jim Redman <ji...@ergotech.com> writes:
> Daniel,
>
> On 2002.06.10 16:14 Daniel Rall wrote:
>
>> protected String getProperty(String name, String defaultValue)
>> {
>> try
>> {
>> return System.getProperty(name);
>> }
>> catch (SecurityException useDefault)
>> {
>> return defaultValue;
>> }
>> }
>
> Will still print to the IE console (that's my recollection at least).
I don't see how that's possible -- the Exception was caught and
handled (assuming that's the right exception type). Does IE's JVM not
implement the Java specification?
> The xmlrpc code looks, for example, like this:
>
> if (parserClass == null)
> {
> // try to get the name of the SAX driver from the System
> properties
> // setDriver (System.getProperty (
> // "sax.driver",
> "org.apache.xerces.parsers.SAXParser"));
> setDriver (System.getProperty (
> "sax.driver", "uk.co.wilson.xml.MinML"));
> }
>
> So that you can set the parserClass and so avoid the getProperty.
The setDriver() method was the one I was thinking about. Yeah, you
can definitely do that. Seems like we have several applet users
about.
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jim Redman <ji...@ergotech.com> writes:
> Daniel,
>
> On 2002.06.10 16:14 Daniel Rall wrote:
>
>> protected String getProperty(String name, String defaultValue)
>> {
>> try
>> {
>> return System.getProperty(name);
>> }
>> catch (SecurityException useDefault)
>> {
>> return defaultValue;
>> }
>> }
>
> Will still print to the IE console (that's my recollection at least).
I don't see how that's possible -- the Exception was caught and
handled (assuming that's the right exception type). Does IE's JVM not
implement the Java specification?
> The xmlrpc code looks, for example, like this:
>
> if (parserClass == null)
> {
> // try to get the name of the SAX driver from the System
> properties
> // setDriver (System.getProperty (
> // "sax.driver",
> "org.apache.xerces.parsers.SAXParser"));
> setDriver (System.getProperty (
> "sax.driver", "uk.co.wilson.xml.MinML"));
> }
>
> So that you can set the parserClass and so avoid the getProperty.
The setDriver() method was the one I was thinking about. Yeah, you
can definitely do that. Seems like we have several applet users
about.
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
Daniel,
On 2002.06.10 16:14 Daniel Rall wrote:
> protected String getProperty(String name, String defaultValue)
> {
> try
> {
> return System.getProperty(name);
> }
> catch (SecurityException useDefault)
> {
> return defaultValue;
> }
> }
Will still print to the IE console (that's my recollection at least).
The xmlrpc code looks, for example, like this:
if (parserClass == null)
{
// try to get the name of the SAX driver from the System
properties
// setDriver (System.getProperty (
// "sax.driver",
"org.apache.xerces.parsers.SAXParser"));
setDriver (System.getProperty (
"sax.driver", "uk.co.wilson.xml.MinML"));
}
So that you can set the parserClass and so avoid the getProperty.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
Daniel,
On 2002.06.10 16:14 Daniel Rall wrote:
> protected String getProperty(String name, String defaultValue)
> {
> try
> {
> return System.getProperty(name);
> }
> catch (SecurityException useDefault)
> {
> return defaultValue;
> }
> }
Will still print to the IE console (that's my recollection at least).
The xmlrpc code looks, for example, like this:
if (parserClass == null)
{
// try to get the name of the SAX driver from the System
properties
// setDriver (System.getProperty (
// "sax.driver",
"org.apache.xerces.parsers.SAXParser"));
setDriver (System.getProperty (
"sax.driver", "uk.co.wilson.xml.MinML"));
}
So that you can set the parserClass and so avoid the getProperty.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"John Wilson" <tu...@wilson.co.uk> writes:
> ----- Original Message -----
> From: "Jim Redman" <ji...@ergotech.com>
> To: <rp...@xml.apache.org>
> Sent: Saturday, June 08, 2002 2:39 PM
> Subject: Re: Dictionary vs. Hashtable in XmlRpc.java
>
>
>> System.getProperty
>>
>> also always throws and prints in IE so that causes more problems in
>> applets.
>
> Jim,
>
> Would explicitly catching the exception help?
That's what's been done in at least some of the client code. A
default value is used instead of the System property. Adding a method
like the following to the XmlRpc class would encapsulate this behavior
nicely:
protected String getProperty(String name, String defaultValue)
{
try
{
return System.getProperty(name);
}
catch (SecurityException useDefault)
{
return defaultValue;
}
}
> It's possible that using java.util.Map, etc. screws JDK 1.x applets anyway.
> I seem to remember that applet jar/zip files could not contain java.*
> classes because of security issues. In which case packaging a subset of the
> Java 2 Collections classes with the applet would not work.
That's correct. However, the separate Collections package is in the
com.sun domain. Don't know if it suffers from the same issues or
not. This discussion is good stuff.
- Dan
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"John Wilson" <tu...@wilson.co.uk> writes:
> ----- Original Message -----
> From: "Jim Redman" <ji...@ergotech.com>
> To: <rp...@xml.apache.org>
> Sent: Saturday, June 08, 2002 2:39 PM
> Subject: Re: Dictionary vs. Hashtable in XmlRpc.java
>
>
>> System.getProperty
>>
>> also always throws and prints in IE so that causes more problems in
>> applets.
>
> Jim,
>
> Would explicitly catching the exception help?
That's what's been done in at least some of the client code. A
default value is used instead of the System property. Adding a method
like the following to the XmlRpc class would encapsulate this behavior
nicely:
protected String getProperty(String name, String defaultValue)
{
try
{
return System.getProperty(name);
}
catch (SecurityException useDefault)
{
return defaultValue;
}
}
> It's possible that using java.util.Map, etc. screws JDK 1.x applets anyway.
> I seem to remember that applet jar/zip files could not contain java.*
> classes because of security issues. In which case packaging a subset of the
> Java 2 Collections classes with the applet would not work.
That's correct. However, the separate Collections package is in the
com.sun domain. Don't know if it suffers from the same issues or
not. This discussion is good stuff.
- Dan
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
On 2002.06.08 07:50 John Wilson wrote:
>
> > System.getProperty
> >
> > also always throws and prints in IE so that causes more problems in
> > applets.
>
> Jim,
>
> Would explicitly catching the exception help?
I'm working from memory, but my recollection is that it prints an
exception in the IE Java console (== tech support call) regardless of
whether you catch it or not.
>
> It's possible that using java.util.Map, etc. screws JDK 1.x applets
> anyway.
> I seem to remember that applet jar/zip files could not contain java.*
> classes because of security issues. In which case packaging a subset
> of the
> Java 2 Collections classes with the applet would not work.
There are a couple of places where the change seems to make little
sense except for consistency, for example, Vector->ArrayList in
WebServer.
Looking through the patch, the following occurs to me. You've already
created the AggregateFactory class, would it be possible to create:
interface MapInterface {
put
get
}
interface ListInterface {
add
get
}
(OR whatever). Then return a concrete implementation from
AggregateFactory. In 1.1 the implementation is a trivial subclass of a
Hashtable and Vector. In Java2, Map and List. Then the
AggregateFactory could be switched to change implementations.
I don't, however, have a good suggestion for Iterators and Enumerations.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Jim Redman" <ji...@ergotech.com>
To: <rp...@xml.apache.org>
Sent: Saturday, June 08, 2002 2:39 PM
Subject: Re: Dictionary vs. Hashtable in XmlRpc.java
> System.getProperty
>
> also always throws and prints in IE so that causes more problems in
> applets.
Jim,
Would explicitly catching the exception help?
It's possible that using java.util.Map, etc. screws JDK 1.x applets anyway.
I seem to remember that applet jar/zip files could not contain java.*
classes because of security issues. In which case packaging a subset of the
Java 2 Collections classes with the applet would not work.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Jim Redman" <ji...@ergotech.com>
To: <rp...@xml.apache.org>
Sent: Saturday, June 08, 2002 2:39 PM
Subject: Re: Dictionary vs. Hashtable in XmlRpc.java
> System.getProperty
>
> also always throws and prints in IE so that causes more problems in
> applets.
Jim,
Would explicitly catching the exception help?
It's possible that using java.util.Map, etc. screws JDK 1.x applets anyway.
I seem to remember that applet jar/zip files could not contain java.*
classes because of security issues. In which case packaging a subset of the
Java 2 Collections classes with the applet would not work.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
System.getProperty
also always throws and prints in IE so that causes more problems in
applets.
Jim
On 2002.06.08 05:51 John Wilson wrote:
>
> ----- Original Message -----
> From: "Daniel Rall" <dl...@finemaltcoding.com>
> To: <rp...@xml.apache.org>
> Sent: Friday, June 07, 2002 1:54 AM
> Subject: Re: Dictionary vs. Hashtable in XmlRpc.java
>
>
> [snip]
>
> > Yeah, we can drop it if anyone wants to submit a patch. I'm still a
> > bit unsure about how this will affect use from applets, but as a 1.2
> > plug-in is available, I'm hoping it won't be a major issue.
> >
>
> The attached patch makes Apache XML-RPC accept any object which
> implements
> Map or List (for struct and array). It builds instances of Hashtable
> and
> Vector for incoming structs and arrays. however that behaviour can be
> changed by setting two system properties, xml-rpc.list and
> xml-rpc.map. For
> example using the following parameters when starting the JVM will
> cause
> HashMap and ArrayList to be used instead of Hashtable and Vector:
>
> -Dxml-rpc.list=java.util.ArrayList -Dxml-rpc.map=java.util.HashMap
>
> I have not committed these changes as the applet issue does not seem
> to have
> been settled yet.
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
System.getProperty
also always throws and prints in IE so that causes more problems in
applets.
Jim
On 2002.06.08 05:51 John Wilson wrote:
>
> ----- Original Message -----
> From: "Daniel Rall" <dl...@finemaltcoding.com>
> To: <rp...@xml.apache.org>
> Sent: Friday, June 07, 2002 1:54 AM
> Subject: Re: Dictionary vs. Hashtable in XmlRpc.java
>
>
> [snip]
>
> > Yeah, we can drop it if anyone wants to submit a patch. I'm still a
> > bit unsure about how this will affect use from applets, but as a 1.2
> > plug-in is available, I'm hoping it won't be a major issue.
> >
>
> The attached patch makes Apache XML-RPC accept any object which
> implements
> Map or List (for struct and array). It builds instances of Hashtable
> and
> Vector for incoming structs and arrays. however that behaviour can be
> changed by setting two system properties, xml-rpc.list and
> xml-rpc.map. For
> example using the following parameters when starting the JVM will
> cause
> HashMap and ArrayList to be used instead of Hashtable and Vector:
>
> -Dxml-rpc.list=java.util.ArrayList -Dxml-rpc.map=java.util.HashMap
>
> I have not committed these changes as the applet issue does not seem
> to have
> been settled yet.
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
The jar is also 250K. After we've hit our application with the Ant
"GenJar" task, that's about the size of the typical application - so
it would double the download time.
The license didn't seem to specifically limit pulling out certain
classes but I wouldn't want to be the final judge of whether that is
legally or technically feasible.
I'm still not opposed to the change if we can resolve the issues. We
have had applications that have exceed Netscape's memory allocation and
we could always use more speed.
Jim
On 2002.06.06 22:07 Tim Peierls wrote:
> Tim Peierls wrote:
> > > There is a 1.1 collections compatibility jar from Sun. Would
> > > that do the trick for your 1.1 user base?
>
> Jim Redman wrote:
> > I can't find the jar to download, nor the license, but in priciple I
> > have no objections. ... And I'm definitly not opposed to performance
> > improvements.
>
> The README is in
>
> http://java.sun.com/products/javabeans/infobus/collectionsreadme.html
>
> and the download (zip, not jar) is via a link from
>
> http://java.sun.com/products/javabeans/infobus/index.html
>
> But right away there's a problem: Collections classes in
> the 1.1 port have been repackaged in com.sun.java.util.collections.
> To use this with the org.apache.xmlrpc code would require some
> fancy Antwork (to build a special 1.1 version of the xml-rpc
> client jar). But it could be done.
>
> --tim
>
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
The jar is also 250K. After we've hit our application with the Ant
"GenJar" task, that's about the size of the typical application - so
it would double the download time.
The license didn't seem to specifically limit pulling out certain
classes but I wouldn't want to be the final judge of whether that is
legally or technically feasible.
I'm still not opposed to the change if we can resolve the issues. We
have had applications that have exceed Netscape's memory allocation and
we could always use more speed.
Jim
On 2002.06.06 22:07 Tim Peierls wrote:
> Tim Peierls wrote:
> > > There is a 1.1 collections compatibility jar from Sun. Would
> > > that do the trick for your 1.1 user base?
>
> Jim Redman wrote:
> > I can't find the jar to download, nor the license, but in priciple I
> > have no objections. ... And I'm definitly not opposed to performance
> > improvements.
>
> The README is in
>
> http://java.sun.com/products/javabeans/infobus/collectionsreadme.html
>
> and the download (zip, not jar) is via a link from
>
> http://java.sun.com/products/javabeans/infobus/index.html
>
> But right away there's a problem: Collections classes in
> the 1.1 port have been repackaged in com.sun.java.util.collections.
> To use this with the org.apache.xmlrpc code would require some
> fancy Antwork (to build a special 1.1 version of the xml-rpc
> client jar). But it could be done.
>
> --tim
>
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Tim Peierls <ti...@peierls.net>.
Tim Peierls wrote:
> > There is a 1.1 collections compatibility jar from Sun. Would
> > that do the trick for your 1.1 user base?
Jim Redman wrote:
> I can't find the jar to download, nor the license, but in priciple I
> have no objections. ... And I'm definitly not opposed to performance
> improvements.
The README is in
http://java.sun.com/products/javabeans/infobus/collectionsreadme.html
and the download (zip, not jar) is via a link from
http://java.sun.com/products/javabeans/infobus/index.html
But right away there's a problem: Collections classes in
the 1.1 port have been repackaged in com.sun.java.util.collections.
To use this with the org.apache.xmlrpc code would require some
fancy Antwork (to build a special 1.1 version of the xml-rpc
client jar). But it could be done.
--tim
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Tim Peierls <ti...@peierls.net>.
Tim Peierls wrote:
> > There is a 1.1 collections compatibility jar from Sun. Would
> > that do the trick for your 1.1 user base?
Jim Redman wrote:
> I can't find the jar to download, nor the license, but in priciple I
> have no objections. ... And I'm definitly not opposed to performance
> improvements.
The README is in
http://java.sun.com/products/javabeans/infobus/collectionsreadme.html
and the download (zip, not jar) is via a link from
http://java.sun.com/products/javabeans/infobus/index.html
But right away there's a problem: Collections classes in
the 1.1 port have been repackaged in com.sun.java.util.collections.
To use this with the org.apache.xmlrpc code would require some
fancy Antwork (to build a special 1.1 version of the xml-rpc
client jar). But it could be done.
--tim
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
Tim,
On 2002.06.06 20:38 Tim Peierls wrote:
>
> There is a 1.1 collections compatibility jar from Sun. Would
> that do the trick for your 1.1 user base?
>
I can't find the jar to download, nor the license, but in priciple I
have no objections. I didn't know the jar existed - we may have use
for it elsewhere. And I'm definitly not opposed to performance
improvements.
My only requirement is that the entire application can be deployed on
the server and viewed in an unmodified web-browser. We can't mandate
plug-ins or browser versions. Seems that the compatibility jar may be
a good solution all round.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
Tim,
On 2002.06.06 20:38 Tim Peierls wrote:
>
> There is a 1.1 collections compatibility jar from Sun. Would
> that do the trick for your 1.1 user base?
>
I can't find the jar to download, nor the license, but in priciple I
have no objections. I didn't know the jar existed - we may have use
for it elsewhere. And I'm definitly not opposed to performance
improvements.
My only requirement is that the entire application can be deployed on
the server and viewed in an unmodified web-browser. We can't mandate
plug-ins or browser versions. Seems that the compatibility jar may be
a good solution all round.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Tim Peierls <ti...@peierls.net>.
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
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Tim Peierls <ti...@peierls.net>.
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
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
We still have a bunch of customers using raw IE and Netscape 4.x. So
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?
Jim
On 2002.06.06 18:54 Daniel Rall wrote:
> Tim Peierls <ti...@peierls.net> writes:
>
> >> On Thu, 2002-06-06 at 13:59, Gus Mueller wrote:
> >> > I was wondering if anyone saw any problems with using a
> >> > Dictionary instead of a Hastable in XmlRpc.java
> >>
> > josh lucas wrote:
> > >
> >> afaik, we are still trying to stay compatible with 1.1 and thus
> >> can't use Dictionary...
> >
> > Dictionary is since 1.0 but is marked as obsolete. So we wouldn't
> > want to use it, not because we are trying to stay compatible
> > with 1.1 but because we want to stay compatible with _later_
> > JDKs. The interface Gus Mueller should really be asking for
> > is java.util.Map, which is indeed not present in 1.1.
>
> Probably a SortedMap or derivative.
>
> > I've been raising the 1.1 compatibility issue every year or so,
> > and the last time I did, Dan Rall got a tentative consensus that
> > XML-RPC could drop 1.1 compatibility. But no one came forth with a
> > patch (myself included).
>
> Yeah, we can drop it if anyone wants to submit a patch. I'm still a
> bit unsure about how this will affect use from applets, but as a 1.2
> plug-in is available, I'm hoping it won't be a major issue.
>
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Daniel Rall" <dl...@finemaltcoding.com>
To: <rp...@xml.apache.org>
Sent: Friday, June 07, 2002 1:54 AM
Subject: Re: Dictionary vs. Hashtable in XmlRpc.java
[snip]
> Yeah, we can drop it if anyone wants to submit a patch. I'm still a
> bit unsure about how this will affect use from applets, but as a 1.2
> plug-in is available, I'm hoping it won't be a major issue.
>
The attached patch makes Apache XML-RPC accept any object which implements
Map or List (for struct and array). It builds instances of Hashtable and
Vector for incoming structs and arrays. however that behaviour can be
changed by setting two system properties, xml-rpc.list and xml-rpc.map. For
example using the following parameters when starting the JVM will cause
HashMap and ArrayList to be used instead of Hashtable and Vector:
-Dxml-rpc.list=java.util.ArrayList -Dxml-rpc.map=java.util.HashMap
I have not committed these changes as the applet issue does not seem to have
been settled yet.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Daniel Rall" <dl...@finemaltcoding.com>
To: <rp...@xml.apache.org>
Sent: Friday, June 07, 2002 1:54 AM
Subject: Re: Dictionary vs. Hashtable in XmlRpc.java
[snip]
> Yeah, we can drop it if anyone wants to submit a patch. I'm still a
> bit unsure about how this will affect use from applets, but as a 1.2
> plug-in is available, I'm hoping it won't be a major issue.
>
The attached patch makes Apache XML-RPC accept any object which implements
Map or List (for struct and array). It builds instances of Hashtable and
Vector for incoming structs and arrays. however that behaviour can be
changed by setting two system properties, xml-rpc.list and xml-rpc.map. For
example using the following parameters when starting the JVM will cause
HashMap and ArrayList to be used instead of Hashtable and Vector:
-Dxml-rpc.list=java.util.ArrayList -Dxml-rpc.map=java.util.HashMap
I have not committed these changes as the applet issue does not seem to have
been settled yet.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Jim Redman <ji...@ergotech.com>.
We still have a bunch of customers using raw IE and Netscape 4.x. So
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?
Jim
On 2002.06.06 18:54 Daniel Rall wrote:
> Tim Peierls <ti...@peierls.net> writes:
>
> >> On Thu, 2002-06-06 at 13:59, Gus Mueller wrote:
> >> > I was wondering if anyone saw any problems with using a
> >> > Dictionary instead of a Hastable in XmlRpc.java
> >>
> > josh lucas wrote:
> > >
> >> afaik, we are still trying to stay compatible with 1.1 and thus
> >> can't use Dictionary...
> >
> > Dictionary is since 1.0 but is marked as obsolete. So we wouldn't
> > want to use it, not because we are trying to stay compatible
> > with 1.1 but because we want to stay compatible with _later_
> > JDKs. The interface Gus Mueller should really be asking for
> > is java.util.Map, which is indeed not present in 1.1.
>
> Probably a SortedMap or derivative.
>
> > I've been raising the 1.1 compatibility issue every year or so,
> > and the last time I did, Dan Rall got a tentative consensus that
> > XML-RPC could drop 1.1 compatibility. But no one came forth with a
> > patch (myself included).
>
> Yeah, we can drop it if anyone wants to submit a patch. I'm still a
> bit unsure about how this will affect use from applets, but as a 1.2
> plug-in is available, I'm hoping it won't be a major issue.
>
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Tim Peierls <ti...@peierls.net> writes:
>> On Thu, 2002-06-06 at 13:59, Gus Mueller wrote:
>> > I was wondering if anyone saw any problems with using a
>> > Dictionary instead of a Hastable in XmlRpc.java
>>
> josh lucas wrote:
> >
>> afaik, we are still trying to stay compatible with 1.1 and thus
>> can't use Dictionary...
>
> Dictionary is since 1.0 but is marked as obsolete. So we wouldn't
> want to use it, not because we are trying to stay compatible
> with 1.1 but because we want to stay compatible with _later_
> JDKs. The interface Gus Mueller should really be asking for
> is java.util.Map, which is indeed not present in 1.1.
Probably a SortedMap or derivative.
> I've been raising the 1.1 compatibility issue every year or so,
> and the last time I did, Dan Rall got a tentative consensus that
> XML-RPC could drop 1.1 compatibility. But no one came forth with a
> patch (myself included).
Yeah, we can drop it if anyone wants to submit a patch. I'm still a
bit unsure about how this will affect use from applets, but as a 1.2
plug-in is available, I'm hoping it won't be a major issue.
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Tim Peierls <ti...@peierls.net> writes:
>> On Thu, 2002-06-06 at 13:59, Gus Mueller wrote:
>> > I was wondering if anyone saw any problems with using a
>> > Dictionary instead of a Hastable in XmlRpc.java
>>
> josh lucas wrote:
> >
>> afaik, we are still trying to stay compatible with 1.1 and thus
>> can't use Dictionary...
>
> Dictionary is since 1.0 but is marked as obsolete. So we wouldn't
> want to use it, not because we are trying to stay compatible
> with 1.1 but because we want to stay compatible with _later_
> JDKs. The interface Gus Mueller should really be asking for
> is java.util.Map, which is indeed not present in 1.1.
Probably a SortedMap or derivative.
> I've been raising the 1.1 compatibility issue every year or so,
> and the last time I did, Dan Rall got a tentative consensus that
> XML-RPC could drop 1.1 compatibility. But no one came forth with a
> patch (myself included).
Yeah, we can drop it if anyone wants to submit a patch. I'm still a
bit unsure about how this will affect use from applets, but as a 1.2
plug-in is available, I'm hoping it won't be a major issue.
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Tim Peierls <ti...@peierls.net>.
> On Thu, 2002-06-06 at 13:59, Gus Mueller wrote:
> > I was wondering if anyone saw any problems with using a
> > Dictionary instead of a Hastable in XmlRpc.java
>
josh lucas wrote:
>
> afaik, we are still trying to stay compatible with 1.1 and thus
> can't use Dictionary...
Dictionary is since 1.0 but is marked as obsolete. So we wouldn't
want to use it, not because we are trying to stay compatible
with 1.1 but because we want to stay compatible with _later_
JDKs. The interface Gus Mueller should really be asking for
is java.util.Map, which is indeed not present in 1.1.
I've been raising the 1.1 compatibility issue every year or so,
and the last time I did, Dan Rall got a tentative consensus that
XML-RPC could drop 1.1 compatibility. But no one came forth with a
patch (myself included).
--tim
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Gus Mueller <gu...@mu.org>.
josh lucas (josh@stonecottage.com) wrote:
> afaik, we are still trying to stay compatible with 1.1 and thus can't
> use Dictionary...
I'm pretty sure Dictionary is part of 1.1-
http://java.sun.com/products/jdk/1.1/docs/api/java.util.Dictionary.html
-gus
--
"Christmas means carnage!" -- Ferdinand, the duck
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Tim Peierls <ti...@peierls.net>.
> On Thu, 2002-06-06 at 13:59, Gus Mueller wrote:
> > I was wondering if anyone saw any problems with using a
> > Dictionary instead of a Hastable in XmlRpc.java
>
josh lucas wrote:
>
> afaik, we are still trying to stay compatible with 1.1 and thus
> can't use Dictionary...
Dictionary is since 1.0 but is marked as obsolete. So we wouldn't
want to use it, not because we are trying to stay compatible
with 1.1 but because we want to stay compatible with _later_
JDKs. The interface Gus Mueller should really be asking for
is java.util.Map, which is indeed not present in 1.1.
I've been raising the 1.1 compatibility issue every year or so,
and the last time I did, Dan Rall got a tentative consensus that
XML-RPC could drop 1.1 compatibility. But no one came forth with a
patch (myself included).
--tim
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by Gus Mueller <gu...@mu.org>.
josh lucas (josh@stonecottage.com) wrote:
> afaik, we are still trying to stay compatible with 1.1 and thus can't
> use Dictionary...
I'm pretty sure Dictionary is part of 1.1-
http://java.sun.com/products/jdk/1.1/docs/api/java.util.Dictionary.html
-gus
--
"Christmas means carnage!" -- Ferdinand, the duck
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by josh lucas <jo...@stonecottage.com>.
On Thu, 2002-06-06 at 13:59, Gus Mueller wrote:
> I was wondering if anyone saw any problems with using a Dictionary instead
> of a Hastable in XmlRpc.java for the function writeObject(Object obj)
>
> My problem is, that when using a Hashtable, the order of the objects put
> in are not kept the same (it uses a hash!) so I had created a class that
> implements Dictionary (which Hashtable does also) and use that instead.
> The result is what I want, and it's works with existing code also.
>
> The diff like this for java/org/apache/xmlrpc/XmlRpc.java
> 785c785
> < else if (obj instanceof Hashtable)
> ---
> > else if (obj instanceof java.util.Dictionary)
> 788c788
> < Hashtable struct = (Hashtable) obj;
> ---
> > java.util.Dictionary struct = (java.util.Dictionary)
> obj;
> 795c795
> < write(nextkey);
> ---
> > chardata(nextkey);
>
>
> and here's the code if it's easier to read for ya:
>
> else if (obj instanceof java.util.Dictionary)
> {
> startElement("struct");
> java.util.Dictionary struct = (java.util.Dictionary) obj;
> for (Enumeration e = struct.keys(); e.hasMoreElements(); )
> {
> String nextkey = (String) e.nextElement();
> Object nextval = struct.get(nextkey);
> startElement("member");
> startElement("name");
> chardata(nextkey);
> endElement("name");
> writeObject(nextval);
> endElement("member");
> }
> endElement("struct");
> }
>
> Does anyone see any problems with this code? Should it be applied to the
> original XmlRpc.java so other folks could possibly benifit?
>
afaik, we are still trying to stay compatible with 1.1 and thus can't
use Dictionary...
Perhaps we should take a vote on that though to see if it is something
we still need to do...
josh
Re: Dictionary vs. Hashtable in XmlRpc.java
Posted by josh lucas <jo...@stonecottage.com>.
On Thu, 2002-06-06 at 13:59, Gus Mueller wrote:
> I was wondering if anyone saw any problems with using a Dictionary instead
> of a Hastable in XmlRpc.java for the function writeObject(Object obj)
>
> My problem is, that when using a Hashtable, the order of the objects put
> in are not kept the same (it uses a hash!) so I had created a class that
> implements Dictionary (which Hashtable does also) and use that instead.
> The result is what I want, and it's works with existing code also.
>
> The diff like this for java/org/apache/xmlrpc/XmlRpc.java
> 785c785
> < else if (obj instanceof Hashtable)
> ---
> > else if (obj instanceof java.util.Dictionary)
> 788c788
> < Hashtable struct = (Hashtable) obj;
> ---
> > java.util.Dictionary struct = (java.util.Dictionary)
> obj;
> 795c795
> < write(nextkey);
> ---
> > chardata(nextkey);
>
>
> and here's the code if it's easier to read for ya:
>
> else if (obj instanceof java.util.Dictionary)
> {
> startElement("struct");
> java.util.Dictionary struct = (java.util.Dictionary) obj;
> for (Enumeration e = struct.keys(); e.hasMoreElements(); )
> {
> String nextkey = (String) e.nextElement();
> Object nextval = struct.get(nextkey);
> startElement("member");
> startElement("name");
> chardata(nextkey);
> endElement("name");
> writeObject(nextval);
> endElement("member");
> }
> endElement("struct");
> }
>
> Does anyone see any problems with this code? Should it be applied to the
> original XmlRpc.java so other folks could possibly benifit?
>
afaik, we are still trying to stay compatible with 1.1 and thus can't
use Dictionary...
Perhaps we should take a vote on that though to see if it is something
we still need to do...
josh