Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 75049 invoked by uid 500); 5 Oct 2001 11:15:54 -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 Delivered-To: moderator for axis-dev@xml.apache.org Received: (qmail 87815 invoked from network); 5 Oct 2001 03:35:37 -0000 Message-ID: <3BBD2A54.3030104@sun.com> Date: Thu, 04 Oct 2001 23:34:44 -0400 From: John Crupi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: jsr110-eg-disc@yahoogroups.com CC: Sam Ruby , axis-dev@xml.apache.org, Glen Daniels , "'jsr-101-experts@eng.sun.com'" Subject: Re: [jsr110-eg-disc] Re: QNames References: <3BBD185B.69BFA85D@sun.com> Content-Type: multipart/alternative; boundary="------------070407010801040306090902" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --------------070407010801040306090902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 --------------070407010801040306090902 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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 aut
henticate 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

--------------070407010801040306090902--