Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 45066 invoked by uid 500); 5 Oct 2001 02:16:19 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 45057 invoked from network); 5 Oct 2001 02:16:18 -0000 Message-ID: <3BBD185B.69BFA85D@sun.com> Date: Thu, 04 Oct 2001 19:18:03 -0700 From: Roberto Chinnici Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Ruby CC: axis-dev@xml.apache.org, Glen Daniels , "'jsr110-eg-disc@yahoogroups.com'" , "'jsr-101-experts@eng.sun.com'" Subject: Re: [jsr110-eg-disc] Re: QNames References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Sam Ruby wrote: > Roberto Chinnici wrote: > > > > How about making QName a concrete, final class with *immutable* > > instances much like java.net.URI in JDK 1.4.0? It doesn't make > > much sense to me to modify a QName after it's been created. > > > > Here's what it would look like (basically, it's Rahul's version, > > made concrete, final and with setters removed): > > > > public final class QName implements Serializable { > > public QName(String localPart) { this("", localPart); } > > public QName(String namespaceURI, String localPart) {...} > > public String getNamespaceURI() {...} > > public String getLocalPart() {...} > > public int hashCode() {...} > > public boolean equals(Object obj) {...} > > > > private String namespaceURI; > > private String localPart; > > } > > If these are immutable, it would be nice if there was a built in mechanism > for them to be pooled. A factory or a static interface to retrieve (or > create) a QName given a localPart and an optional namespace URI would be > handy... Actually in the JAX-RPC RI we had that mechanism, but we got rid of it with no measurable performance penalty. I think that the JVM is pretty good at dealing with small immutable final classes. At the same time, we were careful not to create too many QNames anyway, I guess that helped too. Personally, I've always been a bit suspicious of things like public static QName getQName(String namespaceURI, String localPart); because usually they're implemented by creating a static Map whose contents never get collected. I'd rather have the QName class itself not attempt to cache objects, and let developers write a QNameFactory class that uses a caching strategy appropriate for the application. Roberto