xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Peierls <...@peierls.net>
Subject Re: WebServer.java
Date Fri, 23 Aug 2002 04:41:43 GMT
Ryan Hoegg wrote:
> Wow, a solution to our June discussion may be in sight.  Anyone have any
> objections to using this?
> Dustin Sallings wrote:
> >http://java.sun.com/products/javabeans/infobus/collectionsreadme.html

We went through this in June. Start with this message


and follow the next in thread links.

I still think with some creative Ant work and a willingness to build 
two different jars, one for JDK 1.1 and one for the rest of the world,
this could be done without too many intrusive <filterset> @tokens@. 
Two approaches are:

1. Leave the 1.1-compatible xmlrpc.jar supporting java.util.Hashtable
   and java.util.Vector only as it does now.

2. Use a minimal subset of the com.sun.java.util.collections package
   and include support for both c.s.j.u.c.Map and java.util.Hashtable 
   (and c.s.j.u.c.List and java.util.Vector) for the 1.1-compatible 
   version of xmlrpc.jar.

In either case, for the rest of us :-) use j.u.Map and j.u.List
normally but still allow Hashtable and Vector in method signatures, 
along the lines of John Wilson's patch. (John, what ever happened 
to that patch?)

Incidentally, Hashtable is probably going to be completely reimplemented
for thread-safety in JDK 1.5, so its performance characteristics may
change for the worse in single-threaded use (then again, they may not).

Which reminds me, another good reason to use interfaces instead of
classes for <struct> and <array> is so you can use LinkedHashMap, which
preserves insertion order on iteration, so the members of structs appear 
in a consistent order in XML-RPC requests.



View raw message