[jdom-interest] Last call: getChild/getChildren versusgetChildElement/getChildElements

[Alex Rosen]

Sorry I haven't been keeping up with the mailing list lately, and I'm
coming in to this debate late.

We can't change method names from beta 9 (or really beta 1), it would
just be wrong. It doesn't matter what we said about APIs not being
frozen. It was incumbent upon us to not have a beta cycle that lasted 4
years - we violated any kind of implied contract we had with our users a
long time ago. I think that the old names are really terrible, and if we
had fixed them a couple of months after they were created, then that
would have been great. But fixing them 4 years later is simply
gratuitous and shows no respect for our users. 

If there are more sensible names that we could ADD, and deprecate (but
never remove) the old ones, that would be fine. It would help solve the
problems you're worried about, which are legitimate. Future users, and
future books, would use the new sensible versions, so the bad JDOM
nomenclature wouldn't creep into the rest of the XML world. (I'd be OK
if we did something as sleazy as leave out the deprecated methods from
the 1.0 JavaDoc, but kept them in the code.)

I feel the same way about Parent and Content, if they're likely to
break any significant amount of user code. I haven't been following
closely enough to know if that's the case or not. 

We removed the methods that were deprecated in beta 9, which I guess is
OK since the user was warned. But you could still make an argument that
this will cause gratuitous pain for users, depending on what these
methods were. Some of these methods were added years ago, well before
beta 9, right?

We made a bunch of items private instead of protected. This could cause
code that people wrote 2 or more years ago to suddenly stop working. The
original owner of that code might not be around any longer. Ugh. I
certainly understand the reasoning - if we don't do this, we're locked
into a particular implementation. My only response is: it took us 4+
years to get the FIRST implementation out the door. Are we just kidding
ourselves if we're so worried about FUTURE changes, to the extent that
we break people's existing code? Are we really going to significantly
change this thing much after 1.0? (I.e. why do we think we're going to
do that in the future if we haven't done it in the last 4 years?) If
worse comes to worst, we could always leave the old implementation
alone, and create org.jdom2. (SAX did something like this.)

OK. Now that I got all that out of my system...

Way to go Jason! Go 1.0!!!

Alex