Hi Tobias
From: "Tobias Rademacher" <[EMAIL PROTECTED]>
> what did you think about support of Cannonical XML in dom4j? Will it be
> usefull to
> compare to dom4j-documents that are in cannonical form?
I've never yet thought of a use case where I've needed to do it yet. I can
imagine wanting to compare document fragments for equality, for example that
an Element subtree is equal to another Element subtree.
So a NodeComparator might be useful in the org.dom4j.util package. I'll add
it to the to do list...
> Just another question: What did you think about Java Generics?
I like the look of it. I've wanted Generics for some time in Java though
I've come to realise they are much less important than I once thought. In
C++ it seems that generics (templates) are essential - in Smalltalk or Java
its much less so.
> The Spec is
> already in public review. Unfortunatly java 1.4.0 beta release does'nt
> include the
> new generic collection api. As software that uses old collection api isn't
> affected
> about the changes I'm asking if you will support it one day? What did you
> think? If
> Generics are performant I guess the missing casting will improve
> performance.
I agree there are potential savings, reducing casts. Though for a few years
now JVMs have been really fast at doing casts. I think Generics is more of a
compile time 'feel good factor', allowing you to avoid casts that
technically could fail at runtime and make your code a little simpler. I'm
not sure how much performance is increased. For example, last time I looked
the Generics implementation would often still do the casts under the covers
anyway.
Its certainly something that could be used optionally for those that want
type safety.
For example, if someone wants to use dom4j with Generics they could do
Iterator<Node> iter = element.nodeIterator();
while ( iter.hasNext() ) {
Node node = iter.next();
}
or
Iterator<Element> iter = element.elementIterator( "foo" );
while ( iter.hasNext() ) {
Element foo = iter.next();
}
which would avoid casts and make code more clear.
So ultimately offering Generics support is a good idea IMHO
> We will see.
> Another question: If looked at memory usage at performance test. I seems
> that
> dom4j consumes a little more memory than jdom. Is that true?
Its hard to say for sure. With the 0.4 release of dom4j I'm fairly sure that
dom4j will use less memory than JDOM for most documents, but memory
consumption is quite hard to demonstrate and prove accruately in Java due to
Garbage collection. So I'm not completely sure either way.
> If true, do you
> use
> Flyweightpattern during SAX build up?
Yes dom4j does. It uses the flyweight pattern for Namepaces and QName
objects. A QName is used to represent the local name, fully qualified name
and the Namespace, prefix and URI for an Element or Attribute. So the
following fragment..
<foo xmlns:bar="someBarNamespaceURI">
<bar:something b="123"/>
<bar:something b="456"/>
</foo>
Then there will be flyweight QName objects created for elements <foo> and
<bar:something> together with attribute "b". These flyweights are created
and cached by the DocumentFactory by default and reused for each QName.
Equality is based on prefix, local name and namespace URI.
Deriving a new DocumentFactory allows you to have more fine grained control
over the flyweight policy. For example, the SchemaDocumentFactory (in
org.dom4j.schema package) implements XML Schema Data Types by associating
different DocumentFactory implementations with different QName instances in
a schema.
Also many SAX parsers will 'intern' strings such that the same String
instance is used for repeated element or attribute names.
> I written a small interpreter pattern
> base
> "parser" that also uses the flyweight pattern that decreased the memory
> footprint
> (object instance recycling) and increased the performance as well
(consider:
>
> hashing based storage is fast). So what did you think about that?
Sounds cool.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-user
