axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roberto Chinnici <roberto.chinn...@sun.com>
Subject Re: [jsr110-eg-disc] Re: QNames
Date Fri, 05 Oct 2001 02:18:03 GMT
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



Mime
View raw message