axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Crupi <>
Subject Re: [jsr110-eg-disc] Re: QNames
Date Fri, 05 Oct 2001 03:34:44 GMT
I agree with Roberto.

Roberto Chinnici wrote:

>Sam Ruby wrote:
>>Roberto Chinnici wrote:
>>>How about making QName a concrete, final class with *immutable*
>>>instances much like 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
>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.
>------------------------ Yahoo! Groups Sponsor ---------------------~-->
>Pinpoint the right security solution for your company- Learn how to add 128- bit encryption
and to authenticate your web site with VeriSign's FREE guide!
>To unsubscribe from this group, send an email to:
>Your use of Yahoo! Groups is subject to 

John Crupi
Chief Java Architect
.COM Consulting
Sun Java Center

Cell: 301.526.7890

View raw message