[jdom-interest] API instability?

[Brett McLaughlin]

"Galluzzo, Eric" wrote:
> 
> > "Galluzzo, Eric" wrote:
> > >
> > > We then downloaded a newer version of 1.0b4, which was apparently
> > > still called 1.0b4,
> >
> > You downloaded a daily snapshot of work since 1.0b4 but not
> > yet 1.0b5.
> > They aren't officially versioned.
> 
> Ah, I see!  I didn't realize that. :)
> 
> > > and quite a few of the methods we were using (e.g.
> > > Element.getLongContent()) had not only been deprecated but
> > > actually removed.
> >
> > Those probably should have been deprecated, but considering they were
> > removed partially for lack of use (no one defended them during the
> > debates on whether they should be removed) it wasn't a real concern to
> > deprecate them.  Doing deprecation isn't mandatory; the API is
> > pre-release afterall.  :-)
> 
> Indeed, and that's fine; I'm somewhat of a Johnny-come-lately to JDOM (in
> particular, I just started subscribing to the mailing list on Monday and
> started actually using JDOM about a week before that), so I missed those
> discussions. :)  It's probably no big deal, I can just do a Long.parseLong
> (elem.getContent()), but it's a bit more work.  However, I'm surprised that
> getContent() was deprecated, since it seems like one of the more useful
> methods supplied with JDOM -- one of the differentiators between DOM and
> JDOM.

getContent simply had a name change - it is now getText() and
getTextTrim(). We agree they are major methods that are good, we just
needed better names. It's still there ;-) And yes, the methods that
return getIntContent, getLongContent, etc., were dropped.

Now if you have a compelling use case, we can look at the need for them;
but it was felt the simplicity of the API was improved (something we
like) by removing those methods, because they can, as you point out, be
duplicated in code very easily.

> 
> > You can make an argument on the list for them to be put back
> > in if you'd
> > like.  Just please first check the archives for justifcation
> > on why they
> > were removed.  I say this because I remember someone else missing the
> > methods after they were removed.  (All I can say on missing them after
> > the fact is that if you want to influence the API you have to
> > read your
> > email.  It's easier to defend existing methods than convince people to
> > add methods back.)
> 
> Indeed; again, I only started subscribing to the mailing list on Monday, so
> I'm a bit of a newcomer.

;-)

> 
> > > *  How unstable is the API?  We do not want to have to rewrite
> > > our code every time a new version is released, as we have had to
> > > this time.  If it is too unstable, we will not be able to use it.
> >
> > It's pre-release.  We don't anticipate future changes like
> > we're having
> > between beta4 and beta5, but there will be changes.  Some people can
> > live with that, some can't.  One reason to stay involved before 1.0
> > though is that it's the only way to influence the API.  If you care
> > about what 1.0 looks like, you have to be involved before the API is
> > final!
> 
> We can live with that; our only concern was that there would be massive
> changes like this in every release, since the only experience we have with
> JDOM is 1.0b4-b5.  If there won't be, then that's fine.

No, beta 5 should be the last major change, and then we're mainly doing
bug fixes, performance enhancements, and some new features (not changing
existing ones) for 1.0

> 
> > > * When is 1.0 coming out?  Our manager is afraid of using a pre-1.0
> > > version of JDOM for anything significant, even though it seems
> > > very stable.
> >
> > 1.0 will come out when we collectively are happy with the API and feel
> > the implementation is stable.
> 
> Fair enough.
> 
> > > *  Is there any sort of list of companies successfully using JDOM in
> > > production that we can peruse?
> >
> > Not for me to answer.  I know a lot of important companies are looking
> > into it, and you could use the current code in production probably for
> > certain tasks.  We're addressing issues like should we check
> > for adding
> > and element to itself or not, should we sanity check PCDATA content or
> > not, and should we have a way for an element to get its document or
> > not.  None of that keeps you from using the current API successfully.
> 
> Indeed.  We have been using the API quite successfully and we really rather
> like it.  We've made a couple of tweaks to our own copy which we will submit
> back as proposed patches when we're comfortable that our changes mesh well
> with the rest of JDOM.  The changes are:
> 
>    - add org.jdom.Element DOMBuilder.build (org.w3c.dom.Element)
>      (for use with Apache SOAP)

This is something we are considering as well.

>    - change Element.getChild(String) so that it uses the
>      namespace of the parent instead of the default namespace;
>      if you want the default namespace, you can always pass null

Ah.... this will never get in, because it has some very subtle bugs. A
namespace is part of an Element, not part of an Element's scope. You are
going to run into some tricky bugs when you start moving elements
between documents, or within a document where the namespace scopes
aren't the same. I would advise against this - the trouble of adding the
Namespace is minor, IMO.

>    - make a couple of JDK1.1 fixes

Have you tried build11.bat/sh? If that doesn't work, you should report
the problems.

-Brett

>    - and probably a couple other things which I forgot
> 
> > > * Is there any chance of an "official" JDK1.1 version of JDOM, or
> > > should we keep patching new versions privately when they come out?
> >
> > You should really keep up on the mailing list.  There's been a ton of
> > traffic about this.  JDK 1.1 is already supported in the latest code.
> > build11 is the script.
> 
> That's great!  I'll have to check that out.  Thanks very much for your
> reply.
> 
>     - Eric
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org