I'm happy to announce the release of JDOM 1.1.2 today. It's a drop-in replacement for JDOM 1.1.1 with more than a dozen bugs fixed. You can download the release here:
You can see the changes here:
https://github.com/hunterhacker/jdom/blob/jdom-1.1.2/core/CHANGES.txt
It'll appear in maven-central shortly too.
Thanks to Rolf Lear for doing all the heavy lifting for this release!
You can get the build here:
http://jdom.org/dist/binary/jdom-1.1.1-rc1.zip
http://jdom.org/dist/binary/jdom-1.1.1-rc1.tar.gz
Here's what's new:
Fixed a synchronization issue in the Namespace class that could cause a
hang when doing concurrent builds.
Added output support for Unicode surrogate pairs.
Added a new flag on SAXBuilder named setFastReconfigure() which, when set,
can speed reconfiguration by skipping repeated attempts to set features that
are determined not to be present on a parser. Useful when doing many builds
per second.
Updated the provided Jaxen library from a modified Jaxen 1.0 to the latest
which is Jaxen 1.1.1.
Added reflection code in the error reporting system to support Android's
Dalvik VM which doesn't have the java.rmi.* classes.
I just posted the JDOM 1.1 release. The 1.0 release was very stable and robust, but over time we've fixed enough bugs and added enough small features that it was worth making another formal release.
There's about 20 improvements and bug fixes in all. Details can be found in the jdom-announce email.
I've noticed that XQJ (the XQuery API for Java) has first class support for reading and writing DOM nodes but using JDOM and the other Java-based XML object models requires a lot more work. I'm wondering if that's proper. Is DOM really more popular among Java programmers? There's no sales numbers to compare so let's conduct a little poll. Please select the XML object model you use most (SAX and StAX aren't included as they're not object models).
No fair posting links to this poll to a product-specific mailing list and stuffing the ballot.
Pop the champagne! I just released JDOM 1.0.
Man this feels good. I'm gonna go out with some friends to party tonight, then heading to FOO Camp for the weekend. Ahh. A great moment in life.
It took four years to get here. We should have arrived three years ago. Beta 7 from the fall of 2001 was definitely worthy of being a 1.0 release. Stable, robust, useful. We just didn't call it 1.0 because there were some API changes we wanted to make that would break backward compatibility. We kept the Beta name not for the sake of quality but as a way to warn people about API shifts we saw coming. Was it right to wait? Perhaps not. We could have used 2.0 to indicate an API change like most commercial software.
The good news is we've made the API changes already, we've gotten them widely tested, and we're confident enough in this API that we don't see any reason to break backward compatibility in future releases. So if the Beta moniker kept you from JDOM in the past, it's time to jump on board.
Thanks to everyone who's been involved in the project over the years. It's been an amazing collaborative effort with people the world over contributing code and ideas. I've learned a lot, and met (virtually and in the real world) a lot of great people.
Sorry it took so long. You can't say I don't test my work, though!
Pop the champagne cork, JDOM Beta 10 has been released! OK, perhaps it's a little premature to bring out the champagne for a Beta release, but just barely. This Beta is a major milestone because it's the last scheduled Beta before the official 1.0 release, and things are in good enough shape that 1.0 should ship in mid-March.
It's hard to believe it's been nearly four years since Brett and I met at the O'Reilly Enterprise Conference on Java in Santa Clara and sat on the grass sharing our frustrations with DOM and SAX and planning an API that we'd prefer to use. According to my Palm Pilot calendar, we laid out the vision for JDOM on March 28th, 2000. I figure we'll ship before March 28, 2004. If we can ship 1.0 before it's been a full four years, I can just round down and call it three. :-)
What took it so long? Several things. I discovered XML is "fractally complex". At the highest level it appears only slightly complicated, but as you dig deeper you discover increasing complexity, and the deeper you go the more complicated it continues to become. Trying to be faithful to the XML standards while staying easy to use and intuitive was a definite challenge.
Another issue, perhaps even more important, was that JDOM long ago satisfied all my own use cases. It simply did everything I needed. I started the project because I had an itch to scratch, but the itch had gone away. Why not call JDOM finished at that point? Because there were gaps in areas like encoding internationalized text and XSLT processing and round tripping -- things I don't personally care much about but which needed to be done right. Turns out it's much less motivating to solve other people's problems than your own, so development on my end slowed a lot. Brett had already dropped his involvement in late 2000, so he couldn't lead the project, and others who were active in the project didn't want to take the mantle of leadership.
(Side note: As we got closer to the four year mark, JDOM began to be my own problem again. It wasn't that I had different use cases, I just didn't want to be the guy who never finished JDOM. There's nothing like a little face saving as a motivating factor.)
The third reason for our delayed development was JDOM's involvement in Sun's JCP as JSR-102. When I proposed that JSR, I didn't fully appreciate all the legal roadblocks going against an open source JSR. As Apache's representive to the JCP Executive Committee I fought to clear the roadblocks and in the end was successful (see my past blog posts) -- but that process took two years of wrangling with Sun, ate up much of what you could call my "volunteer energy", and fully exhausted my patience with the JCP. In the end, we haven't pursued JSR-102.
Looking at JDOM 1.0 now, it's going to be the best, most solid, most tested, and most polished 1.0 product I've ever seen. It feels like a version 5.0 product. In fact, it probably should be. Perhaps we shouldn't have worried so much about breaking backward compatibility after 1.0. We could have shipped Beta 7 as "1.0", and called Beta 8 "2.0". That's what happens in the commercial world, and had there been revenue to collect I'm sure we would have done the same thing. There's a "gotcha" with open source -- you don't always feel the same pressure to ship final releases. In some ways that's good because a 1.0 release is truly solid. In others it's bad because the 1.0 release can be too solid.
Whatever the reasons, we're about to ship and I'm thrilled. I want to thank everyone, from users to bug finders to bug fixers to redistributors, whose contributions have made JDOM what it is. I also want to thank by name a few of the core contributors. These are the people I rely on and without whom JDOM wouldn't be half as cool: Jon Baer, Laurent Bihanic, Jools Enticknap, Elliotte Rusty Harold, Brad Huffman, Bob McWhirter, Philip Nelson, and Alex Rosen.
(Q1) What's the status of "update", "insert" and "delete" in XQuery? Is it a few months away, or a couple of years? Are there current proprietary implementations?
(A1) XQuery 1.0 is not scoped to have any update functionality. I've seen proposals for what might go in after 1.0 and they look reasonable and elegant. In the meanwhile what you'll see is custom vendor functions to handle the job. Cerisent for example has functions for inserting and deleting nodes and documents, and these functions work against path expressions nicely. It's really amazing what you can do when you can generate XML that you feed back into the database as input for later queries.
(Q2) Is JDOM going to support XQuery sometime? soon? since it already supports XPath (quite nice, by the way, just used it in my project.)
(A2) I don't really see the situation where you'd want JDOM to "support XQuery". To do XQuery well you want to operate against an indexed data set, and that's not what JDOM is striving to be. It's better if XQuery implementations support JDOM, meaning you could navigate XQuery results with JDOM rather than DOM. This is already possible with Cerisent where their XDBC API lets you get the raw bytes for a result document and you can feed that into JDOM's SAXBuilder. (I keep mentioning Cerisent because it's the engine I'm using myself, as it's by far the most complete.) Keep an eye on the JSR-225 XQJ activity.
(Q3) How much is this query part of XQuery overlapping XSLT? They're certainly of a different type of language. Is XSLT a good analogy for the "View" concept in RDBM?
(A3) XQuery and XSLT are dramatically different languages, although they do have some overlapping uses. I personally find XQuery much more natural to use, and expect other traditional programmers will as well. I wouldn't be surprised if XQuery saw uses where traditionally one might have used XSLT previously. In classes I've taught on XQuery, students seemed to catch on faster than with XSLT.
(Q4) Are there datatypes in XQuery? Or just all variables are intepreted from its context like in most scripting languages?
(A4) XQuery is a strongly typed language, with typing mostly based on the XML Schema types (i.e. xs:decimal) with a few new types added by XQuery itself. You can also define your own types using Schema. If you don't like Schema (who does?) the wonderful thing is that in the absence of typing the data values are typed as xdt:untypedAtomic (xdt is the custom namespace prefix for the set of types added by XQuery) and the rules for this untyped type allow automatic casting to string and numeric values as required. Thus the simple uses work in a way that will remind you of Perl, but you can also strongly type your data if you want. I personally think the strong typing is most important when your data source is an RDBMS where values are naturally typed and so it's more efficient and easier if you don't have to artificially "untype" them.
The March/April issue of Oracle Magazine has a new "JDOM in the Real World" article showing how I use JDOM to manage the RSS feeds on Servlets.com, including how I get this entry to show up on the front page.