Slashdot Mirror

No, he probably means like C#'s XML serialization / de-serialization

You mean, something like Java's XMLEncoder? Nope, Java was still there first. Perhaps you're referring to the way DOM nodes can be queried directly via XPath?

That's certainly a nice feature that's not part of the core. No matter, we've been using libraries like JDom to XPath for quite a long time. :-)

Oh, and what's the difference between the 3587324 different XML parsing packages?

Just pick one. Like JDOM.

Sure, it's not "portable", but just do what Perl and Python have done

You can do that yourself with a System.exec call. I'm sure there's some jars out there that do just that.

Actually, this is VERY IMPORTANT! I think the big advantage(s) of "open sourcing" java will be seen when things such as the mess with the logging API's and the use of the assert keyword are avoided.

It is still a mystery to me why Sun developed their own logging API's when LOG4J was widely used and accepted.

Hopefully a more open approach to Java would help projects that are housed at Jakarta and SourceForge actually make it into the JDK instead of sticking us with inferior rewrites.

The logging API is just one example. Imagine if the JUNIT implementation of assert was used, and if SWT could be combined with Swing/AWT to create better/superior user interfaces. I think Java could grow in leaps and bounds with an open approach.

Another good example of this would be the JDOM project. How long has it sat in the JCP? While in the meantime Sun implemented their own INFERIOR XML libraries.

The JCP is too political, and needs to modified/done away with. Let the people decide the direction of JAVA!

Just my .02

--Ryan

There's one more thing you need: JDOM. It's basically a wrapper for XML parsers that make manipulating XML in Java much less painful. It's good enough, in fact, that Sun has adopted it as a JSR (JSR 102, I think). I bumped into it a few months ago, and it's already made a huge difference in terms of productivity. With JDOM you spend less time worrying about all the oddities of the DOM or the limits of SAX - instead you mess with good ol' Java objects and JDOM does the rest.

In fact, JDOM is a part of the Java Community Process as Java Specification Request 102.

Sun comment about JDOM:

In general we tend to prefer to avoid adding new APIs to the Java platform which replicate the functionality of existing APIs. However JDOM does appear to be significantly easier to use than the earlier APIs, so we believe it will be a useful addition to the platform.

i really liked brett mclaughlin's book
java and xml from o'reilly
he's also involved with the Jdom project which is a cool set of java classes that make working with xml fast and easy.

I thought about using JDOM (especially after reading Brett McLaughlin's Java and XML), but I hesitate to use it right now because it is still in beta. The absence of release, milestone, or even nightly builds at http://www.jdom.org/downloads/index.html adds to my discomfort with JDOM. Don't get me wrong - I think JDOM is a great idea - but I will have a hard time justifying to my co-workers the use of beta software in building a system that should go into production within the next two months. For now, I've decided to use Xerces, partly because it is well-documented (I found the DOMFilter example code to be particularly useful) and partly because some of my co-workers have already used the C++ version.

There is no compelling reason for a Java API to manipulate XML to be complex, tricky, unintuitive, or a pain in the neck. JDOM is both Java-centric and Java-optimized. It behaves like Java, it uses Java collections, it is completely natural API for current Java developers, and it provides a low-cost entry point for using XML.

We've been using it at work and are happy with it so far.