[jdom-interest] Another plea for Interfaces and other musings

[Maximilian A. Ott]

I have been using JDOM since last summer in our product as well as in a
graduate class I'm teaching to an audience with little XML experience. For
whatever reason I completely missed this newsgroup.

Over time I have added stuff (such as a builder factory) to support the
things we are doing. Recently I been evaluating our requirements and I admit
having some problems positioning JDOM.

My main interest is not in XML (one can view it is as just a glorified
encoding scheme), but in manipulating tree structures. So in some of our
implementations, elements are not just passive representations, but active
objects where the name/NS identifies their semantics (that's why I needed a
factory). I also have a more relaxed view of the parent/child relationship
in that I'm not sure that the single parent restriction is a sacrosanct one.
But I know too little about the XML standards to judge if that is a fixed
requirement. I wonder if there was already a discussion on that I missed
when looking through the archives.

Is it essential to be able to walk up the tree? Or is it enough to just be
able to walk down? If the same sub-tree can be attached to multiple parents
it makes many things much easier (at least for me). Obviously, there is the
possibility of loops (but we are all software professionals and don't do
that :)

One thing which struck me as odd, was the omission of interfaces. I read
with great interest the discussion last December and better put on my
asbestos suit here as the exchange was quite heated.

Jason (I think) was very vocal about no one ever having presented a good
enough user case. That got me thinking. Why am I always starting with an
interface? Just old habit? Not really. I have been building distributed
computing middleware for the last 15 years and I can't frankly think of any
other way to provide "location transparent" object references in a strongly
typed language without interfaces. If I want to return a reference to an
element in a remote call I need an interface to allow the remote side to
build the stub.

Despite the web, the grid, what-have-you, I'm most likely representing a
very small group wanting distributed computing abstractions.

Better let's re-visit the arguments against:

* Needs factories and they are "in-your-face":
----------------------------------------------

I still don't understand the "in-your-face" argument. In fact, I have found
factories one of the cleanest constructs to hide heterogeneity from the user
of a framework. But I agree, "new" is being discussed on page 5 of any
introductory book on Java, "factories" most likely don't even make the cut
until the advanced version.

Would we really need factories with interfaces? There seem to be no way
around them for creating the initial Document (bootstrapping). But after
that?

Element addRootElement(String name, Namespace ns)

And for the Element themselves:

Element addElement(String name, Namespace ns)
^^^^ Note, this returns the newly added element and not the element
modified.

Obviously, there is a desire to limit the number of methods of each class,
but that is always a balancing act.

I know there would be other issues to consider. For instance, all the addXXX
calls return the modified object, allowing chaining of calls. My above
suggestion changes the semantics of that return which could be confusing.
But I'm sure that if one takes the time to through all that carefully, a
common semantics can be established.

* Performance:
--------------

That argument was only mentioned in passing, but might indeed be the real
reason for trying to avoid interfaces at all cost.

I admit that I have so far never worried about performance of my Java
implementations. They were all "proof-of-concept", and clean design and
extensibility was the major goal. That will change soon as I'm in the
process of populating a rack with server to build a testbed and have a
student standing by to try to bring everything to its knees and create a lot
of graphs in the process.

I'm wondering if anyone could comment on the overhead of interfaces in Java.
I have a very good understanding of the trade-offs for C++, but not for
Java.

* Wrong tool:
-------------

As mentioned at the beginning, I'm starting to wonder if JDOM is even the
right library for doing anything beyond reading XML files and creating a
representation of some internal data set to be written out as XML. Similar
to the serialization layer in ORBs (CORBA, RMI, COM, may add SOAP as well).
Maybe the "users" of these frameworks soon don't see that anymore, but use
tools such as IDL, or better here, CATO and the likes to map the
"persistence" representation of XML files/DB, or wire representation (SOAP)
to "pure" objects (I know CORBA and the like  and the like require you to
subclass from their specific "Object" classes, but that is not necessary and
just pure laziness on the side of the ORB designers - ok, the standards
writers, too).


If you are still reading, thanks!

Comments would be greatly appreciated.

Thanks again,

-max

---
Maximilian A. Ott
semandex.net                       tel:+1.609.720.4913


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com