[jdom-interest] NoSuch*Exceptions in JDOM
Jim Rudnicki
jdr5list at pacbell.net
Sun Jun 18 13:07:08 PDT 2000
> > Alas, there is no hasChild() ?
>
> You know, I was halfway into proposing such a method when I stopped to
> give it some more thought. It lets you write code
>
> if (elt.hasChild("foo")) {
> Element child = elt.getChild("foo");
> }
> else {
> // deal with none
> }
>
> which is debatably better to read. The reason I wanted to think more
> about it was that hasChild() would have to do an O(n) scan through the
> children, then getChild() would have to do the same scan. Course, we
> could cache the hasChild() ...
Stand your ground. getChild should not be a function that either tests for
non-existence or retrieves. Returning null is just like the nightmarish new
operator in C++. We all ASSERT every single new right? sure ya do. Nobody
ever runs out of memory, why bother testing for null.:)
As you propose the efficiency hit looks severe, but it is a trivial code
snippet. Trivial programs will run fast enough, why break design to
optimize for them. A more complex program would do stuff with the child
"foo", that would make the hit look smaller. Also, if a program is
dominated by repeatedly scanning over large sections of the tree with
getChild() wouldn't the good answer be "stop it". In later releases provide
a SortedElement, or HastableElement that use memory to eliminate the scan
hit. Something along those lines could reduce getChild much more the 1/2x.
For the old schoolers, give em this:
package org.jdom.not; // :)
class OldElement extends Element {
Element getChild( String strTagName ) {
Element elRet;
try {
elRet = super.getChild( strTagName );
}
catch( NoSuchElementException x ) {
elRet = null;
}
return eRet;
}
}
Received: from mail.netmagic.net (netmagic.net [206.14.125.10])
by dorothy.denveronline.net (8.9.3/8.9.3) with ESMTP id PAA28794
for <jdom-interest at jdom.org>; Sun, 18 Jun 2000 15:38:23 -0600 (MDT)
Received: from Tatooine (ppp4-36.sj.netmagic.net [209.24.168.36])
by mail.netmagic.net (8.9.3/8.9.3) with SMTP id OAA02842;
Sun, 18 Jun 2000 14:45:15 -0700
Message-ID: <000701bfd96e$4ad70a20$d9ebc8d8 at flashcom.com>
From: "Bryan Brown" <bbrown at netmagic.net>
To: "Jim Rudnicki" <jdr5list at pacbell.net>, <jdom-interest at jdom.org>
References: <27FF4FAEA8CDD211B97E00902745CBE2013D2F87 at seine.valicert.com><003601bfd8df$c666dd80$3301a8c0 at pacbell.net> <394CEEBE.D493EF19 at collab.net> <002801bfd960$c87baf20$3301a8c0 at pacbell.net>
Subject: Re: [jdom-interest] NoSuch*Exceptions in JDOM
Date: Sun, 18 Jun 2000 14:43:50 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: jdom-interest-admin at jdom.org
Errors-To: jdom-interest-admin at jdom.org
X-BeenThere: jdom-interest at jdom.org
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: JDOM Mailing List for General Issues and Updates <jdom-interest.jdom.org>
----- Original Message -----
From: "Jim Rudnicki" <jdr5list at pacbell.net>
To: <jdom-interest at jdom.org>
Sent: Sunday, June 18, 2000 1:07 PM
Subject: Re: [jdom-interest] NoSuch*Exceptions in JDOM
>
> > > Alas, there is no hasChild() ?
> >
> > You know, I was halfway into proposing such a method when I stopped to
> > give it some more thought. It lets you write code
> >
> > if (elt.hasChild("foo")) {
> > Element child = elt.getChild("foo");
> > }
> > else {
> > // deal with none
> > }
> >
> > which is debatably better to read. The reason I wanted to think more
> > about it was that hasChild() would have to do an O(n) scan through the
> > children, then getChild() would have to do the same scan. Course, we
> > could cache the hasChild() ...
>
> Stand your ground. getChild should not be a function that either tests
for
> non-existence or retrieves. Returning null is just like the nightmarish
new
> operator in C++. We all ASSERT every single new right? sure ya do.
Nobody
> ever runs out of memory, why bother testing for null.:)
>
> As you propose the efficiency hit looks severe, but it is a trivial code
> snippet. Trivial programs will run fast enough, why break design to
> optimize for them. A more complex program would do stuff with the child
> "foo", that would make the hit look smaller. Also, if a program is
> dominated by repeatedly scanning over large sections of the tree with
> getChild() wouldn't the good answer be "stop it". In later releases
provide
> a SortedElement, or HastableElement that use memory to eliminate the scan
> hit. Something along those lines could reduce getChild much more the
1/2x.
>
> For the old schoolers, give em this:
>
> package org.jdom.not; // :)
>
> class OldElement extends Element {
> Element getChild( String strTagName ) {
> Element elRet;
> try {
> elRet = super.getChild( strTagName );
> }
> catch( NoSuchElementException x ) {
> elRet = null;
> }
> return eRet;
> }
> }
>
I agree with Jim on this one, and if we are concerned about the performance
of a hasChild() routine then use a hashtable to store the children and then
hasChild() is an efficient operation.
-Bryan
XML-Technologies.com
http://www.XML-Technologies.com
Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143])
by dorothy.denveronline.net (8.9.3/8.9.3) with ESMTP id NAA11129
for <jdom-interest at jdom.org>; Fri, 16 Jun 2000 13:31:25 -0600 (MDT)
Received: from sasha ([24.147.232.47])
by chmls05.mediaone.net (8.8.7/8.8.7) with SMTP id PAA23266;
Fri, 16 Jun 2000 15:31:21 -0400 (EDT)
Message-ID: <00ad01bfd7c9$2508df40$6601a8c0 at sasha>
Reply-To: "Anne Thomas Manes" <anne at manes.net>
From: "Anne Thomas Manes" <annethomas at earthlink.net>
To: "Jon Baer" <jonbaer at digitalanywhere.com>
Cc: <jdom-interest at jdom.org>
References: <200005081342.JAA03630 at hesketh.net> <00f101bfd79c$7807f280$6601a8c0 at sasha> <394A2DE7.9662A34F at digitalanywhere.com>
Subject: Re: [jdom-interest] SOAP?
Date: Fri, 16 Jun 2000 12:25:41 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: jdom-interest-admin at jdom.org
Errors-To: jdom-interest-admin at jdom.org
X-BeenThere: jdom-interest at jdom.org
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: JDOM Mailing List for General Issues and Updates <jdom-interest.jdom.org>
Sun does not have an "alternative" to SOAP. Certainly you have many
alternatives to SOAP, but most involve writing your own XML data encoding
routines and message envelopes. SOAP automates this process, so therefore
obviously adds value. But be aware that SOAP is a very simple protocol
(remember that the "S" in SOAP stands for "simple"). It doesn't do a lot of
the things that RMI does -- it doesn't do distributed garbage collection. It
doesn't support versioning. It doesn't support security or transactions. In
fact, it doesn't even have a related object model. Which is one of its
primary features in terms of interoperability. But therefore it doesn't
support dynamic classloading, pass by value, and other useful features.
Sun is also involved in the ebXML initiative (see http://www.ebxml.org), a
joint effort of OASIS and UN/CEFACT that is working to develop XML-based
standards and infratructure to support the rigorous requirements of
electionic business and international trade. ebXML is developing a much more
robust XML middleware solution, including a transport, routing, and
packaging service. This service will support security, transactions,
versioning, and other rigorous requirements. A prototype of the transport
service is complete.
There are three XML-related Java APIs. One is shipping, and two are in
development.
- Java API for XML Parsing (JAXP) provides an interface to SAX and DOM. JAXP
is shipping.
- Java XML Data Bindings converts Java objects to XML and vice versa. Java
XML Data Bindings is in development, and the spec should be available by end
of year.
- Java API for XML Messaging (JAXM) provides an interface to an XML
messaging service such as SOAP and ebXML. JAXM might provide some automatic
services such as dynamic class loading.JAXM is in the CAll For Experts
(CAFE) stage of JCP.
For more information about these APIs, visit http://java.sun.com/jcp
Anne Manes
----- Original Message -----
From: "Jon Baer" <jonbaer at digitalanywhere.com>
To: "Anne Thomas Manes" <anne at manes.net>
Cc: <jdom-interest at jdom.org>
Sent: Friday, June 16, 2000 6:38 AM
Subject: Re: [jdom-interest] SOAP?
> In some ways I want to say it seems that SOAP is all the ways RMI should
have
> been but the spec has no mention of security and (from what I have read,
could
> be wrong) no way for dynamic classloading via the XML doc, the 2 objects
must
> live on both machines in order for them to communicate via XML and use the
> objects.
>
> What is Sun's alternative to SOAP? Dont they already have an XML
middleware
> solution?
>
> - Jon
>
> Anne Thomas Manes wrote:
>
> > FYI:
> >
> > Thought you might be interested in this comparative review of the IBM
and
> > Microsoft SOAP implementations.
> >
> > http://windows.oreilly.com/news/soapreview_0600.html
> >
> > By the way, Sun is less unhappy about SOAP than before.
> >
> > Anne Manes
> >
> > ----- Original Message -----
> > From: "Simon St.Laurent" <simonstl at simonstl.com>
> > To: "Jon Baer" <jonbaer at digitalanywhere.com>; <jdom-interest at jdom.org>
> > Sent: Monday, May 08, 2000 6:44 AM
> > Subject: Re: [jdom-interest] SOAP?
> >
> > > At 05:57 AM 5/8/00 +0000, Jon Baer wrote:
> > > >Ehhh anyone know anything about this:
> > > >http://msdn.microsoft.com/workshop/xml/general/soapspec.asp
> > > >
> > > >Would there then be a need to develop a SOAPBuilder? Is anyone using
> > > >this protocol?
> > >
> > > Lots of people are using SOAP for various things. Check out:
> > > http://www.xmlhack.com/list.php?cat=25
> > > for news on SOAP and other XML protocols.
> > >
> > > Sun seems deeply unhappy with SOAP, while Microsoft seems quite
pleased by
> > > it. IBM's joined the SOAP side of this issue. It'll be a long while
> > > sorting out.
> > >
> > > The good news is that SOAP messages are plain old ordinary XML (simple
at
> > > that), and shouldn't need a specific builder - just some logic and a
> > > connection to HTTP.
> > >
> > > Simon St.Laurent
> > > XML Elements of Style / XML: A Primer, 2nd Ed.
> > > Building XML Applications
> > > Inside XML DTDs: Scientific and Technical
> > > Cookies / Sharing Bandwidth
> > > http://www.simonstl.com
> > >
> > > _______________________________________________
> > > To control your jdom-interest membership:
> > >
> >
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> > t.com
> > >
> > >
>
>
More information about the jdom-interest
mailing list