XOM API for Processing XML with Java

[Tatu Saloranta <cowtowncoder AT yahoo.com>]

2.5 years since the first non-beta release means that anyone with a brain 
only started using Java 5 in production, say, 1.5 years ago. And by now, 
significant portion of existing systems are being moved over; at least ones 
still developed. Big corporations move slow -- sometimes for right, sometimes 
wrong reasons.

Just because individual developers can afford to develop on leading edge does 
not mean everyone can. And more fundamental a library is, slower it should 
(in my opinion) move. Further, benefits of Java5 generics are generally 
exaggerated by people; especially so for retro-fitting them in. For new 
projects I find it more sensible to start with Java5. For mature libraries 
like XOM (or Lucene etc) there's much less incentive. Java5 is just icing on 
the cake, fluff but not much stuff (except for concurrency packages).

Anyway, this discussion is boring since it's been done over and over again 
not only here, but also on JDOM and Lucene lists, and probably dozens others 
that I do not follow.

-+ Tatu +-

----- Original Message ----
From: Randall R Schulz <rschulz AT sonic.net>
To: xom-interest AT lists.ibiblio.org
Sent: Tuesday, May 29, 2007 6:46:45 PM
Subject: Re: [XOM-interest] Iterable Elements

Elliotte,

On Tuesday 29 May 2007 18:17, Elliotte Harold wrote:
> Cass Costello wrote:
> > What are the disadvantages you see, Elliotte?
>
> Incompatibility with everyone still on 1.4 is the big problem.

Java 5 / 1.5 was released by Sun two years and eight months ago today. 
We're very far out from that release. Compatibility with 1.4 is a 
dinosaur problem, and it is highly dubious whether institutions that 
cannot find a way to migrate to 1.5 should dominate the decisions of 
library providers.


> It would also needlessly duplicate functionality in the API. In XOM
> there's exactly one way to do it, and Iterator isn't it. Use a
> NodeList.
>
> Finally, you'd have to figure out what to do about the remove()
> operation. I don't think there's a good answer for that. 

There's no obligation to implement remove(). You can throw an 
OperationNotSupportedException while remaining compliant with the API 
specification. See <http://java.sun.com/j2se/1.5.0/docs/api/> for 
confirmation.


> XOM quite deliberately does not expose overly generic collections
> APIs that don't perfectly fit the problem space. I don't intend to
> start now.

Iteration over interior nodes does not "perfectly fit" an object model 
that is strictly tree structured? That's hard to accept or defend.


Randall Schulz
_______________________________________________
XOM-interest mailing list
XOM-interest AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/xom-interest





       
____________________________________________________________________________________Get
 the free Yahoo! toolbar and rest assured with the added security of spyware 
protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php