[jdom-interest] Why not interfaces?

[Paul Philion]

Note: This post contain my opinions about the role of interfaces in
Java software. If you are not interested, please delete.

Let's see if I have this correct:

Using interfaces in JDOM was scrapped because:

a) You can't dictate the behavior of equals().
b) It was more difficult to design and implement.

(If I've missed something, please let me know. I reviewed the
archives, and those are the issues that were discussed.)

An interesting comment from the archive:

    Before we would add something like that [...]
    we'd need a compelling and common use case
    for what someone would do with the
    functionality that can't be solved elegantly
    using the existing feature set.

Jason said that.

Jason, can you meet that criteria for the decision to remove
interfaces?

I don't think a) provides a "compelling" reason: The interface
document can clearly state that equals() should check for specific
instance equality. Sun takes this same route when documenting the
dependency between equals() and hashCode().

I don't think b) is a compelling reason either, as good design and
implementation are difficult, especially for simple, robust software.

Now, a clear and compelling use case for using interfaces:

  Parsing large, complex XML documents.

JDOM fails the same was DOM does: Before a document can be used, it
must be completely parsed. If you don't have enough memory, to bad. If
you're running on a small device, too bad. If you only need a few
important pieces in the document, too bad.

IF JDOM supported interfaces, I could implement a version of Document
that only parsed as much of the document as was necessary to provide
the requested data.

IF JDOM supported flexible factories, I could implement a light weight
caching parser that returned my on-demand Document.

Neither of these is possible today. Further, because of the concrete
nature of JDOM, it is less capable of handling unexpected needs in the
future.

Several people (in the archive) argued to use interface in "JDOM2". I
ask: "Why wait?"

- Paul Philion


> -----Original Message-----
> From: Jason Hunter [mailto:jhunter at collab.net]
> Sent: Thursday, September 07, 2000 5:29 PM
> To: Paul Philion
> Cc: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] Why not interfaces?
>
>
> > I missed the original. Is there somewhere I can review it
> online? I
> > don't want to rehash a discussion that has already been had.
>
> The archives are online via the link from the web site.  Not easy to
> search except download a month and CTRL-F but it gets the job done.
>
> > 1) Making the Document thread-safe.
> >
> > - Looking over the latest code, Document is not
> thread-safe. I would
> > recommend a solution similar to the one offered by the Java 1.1
> > collections. Have a "standard" implementation that is *not*
> > thread-safe, and a method on the Document builder that is
> > "buildSynchronized", that wraps a synchronized wrapper around the
> > document.
>
> The FAQ addresses this.  We leave it to the programmer
> because we can't
> do much thread safety within the class, most has to be
> external, so we
> let all be external.
>
> > 2) Mandating how equals is handled.
> >
> > - One suggestion is to have a static utility method to
> compare to two
> > Documents. The "standard" implementation would use this. Novel
> > implementations of the Document (if it was an interface)
> could also
> > use it.
> >
> > I'm sure that you covered this, and other issues in your
> recent post.
> > I'd really like to read it before I step in it too deeply.
>
> I didn't write all *that much* about it because I know
> interfaces aren't
> something we're willing to switch (back) to.  We actuall
> started with
> interfaces in our private impls before going public, and
> believe me we
> were MUCH happier about the design with concrete classes.
>
> -jh-