[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