axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Crupi <john.cr...@sun.com>
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 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
>
>
>
>------------------------ 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!
>http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/saFolB/TM
>---------------------------------------------------------------------~->
>
>To unsubscribe from this group, send an email to:
>jsr110-eg-disc-unsubscribe@yahoogroups.com
>
> 
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
>
>

-- 
John Crupi
Chief Java Architect
.COM Consulting
Sun Java Center

Cell: 301.526.7890



Mime
View raw message