Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

JDOM 2.0

rolfl edited this page · 28 revisions

This page describes the effort toward a JDOM 2.0. The purpose of JDOM 2.0 is to make use of features introduced in Java 5, such as generics. Unfortunately the generics changes will break binary backward compatibility so we're moving to a new version as well as a new package name: org.jdom2. People who want to use the JDOM 1.1.x branch can continue to do so, but people who want the modern features can use JDOM 2.0. The same program can even mix and match. Yes there's downsides ((http://markmail.org/message/avsyrgfii7z3u6m5) but it's probably worth it.

How much backward compatibility will we break? Only what's necessary. We may maintain source code compatibility so all a programmer will need to do is update their package imports and recompile their project. But if we decide as a group that some changes are so advantageous they're worth requiring code edits, we'll do it.

We'll do the work on GitHub because it simplifies the task of doing experimental branches. I expect a lot of discussion about whether a certain change is worthwhile or not, and GitHub makes it easy to discuss code not just ideas. The JDOM mailing lists will host the discussion. You can also watch for updates on Twitter from @jdomproject and @jdomcommits.

Possible JDOM 2.0 improvements (each should probably get a wiki page):

People who have volunteered to be heavily involved in the project:

Initial steps:

  1. Migrate the code from CVS to GitHub (keeping all the history). DONE - see SOURCE
  2. Create a branch for 2.0 DONE - see Source Branches and JDOM2
  3. Do the basic package renames.
  4. Fix the test case that's currently failing (test_TCM__void_setExpandEntities_boolean)
  5. Upgrade the JUnit libraries and tests.
  6. Use 'Emma' http://emma.sourceforge.net/ to build up the JUnit test cases to get much better coverage of the junit tests on JDOM (currently have only got 40% coverage of the org.junit code from the JUnit test cases....). Fix any issues that arise in untested code.
  7. Modify the core code and the test harness together to implement the changes - document what changes are made so that we can get a list of rules for migration from JDOM 1 to JDOM 2.
  8. Confirm any deviations from 'compatibility' with the jdom-interest list to ensure that all changes are reasonable.
  9. Complete the migration, ensure all JavaDoc is complete. All Tests are run, and code test coverage is 'complete'.
Something went wrong with that request. Please try again.