[jdom-interest] Todo list [eg]

Jason Hunter jhunter at collab.net
Fri Apr 27 17:18:56 PDT 2001


> > According to JSR definitions, JDOM is approaching community review.  :-)
> 
> This brings up a question. In your opinion, what things on the TODO list need
> to happen before we can get to each stage of the JSR? 

I'd *really* like it if we could have no known pending public API
changes when we went to community review.  We're pretty close.

> Does i18n need to move from JDOM 1.1 to 1.0, now that JDOM is a JCP spec?

Not really.  i18n is an implementation detail.  The API won't change. 
So we can declare the API 1.0 final and the 1.0 RI can not support i18n,
but a 1.0.5 version can add i18n support.

> Think more about subclassing. 

We have Joe beating us on the head with that one.  :-)

> Make more (all?) variables and methods protected
> instead of private. 

Anything protected is essentially part of the public API.  We would need
to be absolutely sure that the variable belongs there forever before
making it protected.

> Split long implementation methods up as much as makes
> sense, so that you can override base functionality at a more granular level.
> (You don't have to copy the code from a large method, just so you can change
> one small piece of it.)

This involves protected methods.  Same considerations as above.

> Remove the 3 Document.getProcessingInstruction[s] methods. I think they're not
> needed, and cause confusion. See the discussion at
> http://lists.denveronline.net/lists/jdom-interest/2000-November/003882.html and
> again at
> http://lists.denveronline.net/lists/jdom-interest/2001-January/004244.html
> (nobody requested to keep them). Now that I think about it, I think
> removeProcessingInstruction[s] and setProcessingInstructions should go too.

Yep, I'll remove them after I finish this email.  (Depracating until
after beta7 of course for backward compatibility.)

> XMLOutputter.printDeclaration() knows that it should write encoding="UTF-8"
> rather than encoding="UTF8". I think we need to add a long list of translations
> from Java encoding names to standard encoding names, or we'll print the wrong
> thing when using other encodings.

Do you have other examples where it's necessary?

-jh-

P.S.  Care to submit a patch to the TODO?



More information about the jdom-interest mailing list