struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Options1: Just Say No (was Re: cvs commit: jakarta-struts/web/documentation tags.html)
Date Mon, 17 Jul 2000 17:32:16 GMT
David Geary wrote:

> >   <struts:options1> is a version of <struts:options> that is compatible
> >   JDK 1.1, and can enumerate over an array, a Dictionary (including a
> >   Hashtable), an Enumeration, or a Vector.
> I'm sorry, but this is horrible. Why? For the same reason that struts tags are not named
tag1, tag2, tag3, ...
> We have EnumerateTag, which is for 1.1, and IterateTag, which is for 1.2. That's bad
enough, but at least it's apparent which tag
> applies to what version of the JDK; that is, if you know that Iterator was added in 1.2,
and you understand that there is no difference
> between EnumerateTag and IterateTag except for their private iteration algorithm, which
really should be nobody's business but their
> own.
> Now we have OptionsTag and Options1Tag, which share all of the drawbacks that EnumerateTag
and IterateTag exhibit, but in addition:
> Which tag is for 1.1 and which is for 1.2?
> Please don't force me to select which JDK version is supported by struts tags by using
different tags with obscure names. All struts
> tags should work with both 1.1 and 1.2 collections. Developers shouldn't even have to
think about it.
> The worst part of all this is that a simple implementation of the Adapter design pattern
can eliminate all of the duplicate classes,
> leaving us with just IterateTag and OptionsTag.

Having a single version of each tag is the ideal scenario, and is used
in *most* of the Struts tags.  The only cases where there are two
versions is when a tag wants to use the Java2 collections classes.

So, let's say I want to have just one version of the "options" tag (for
example, that supports collections if they are there, and doesn't
if they are not there (do you ***really*** want to find out about this
kind of problem at runtime instead of compile time?  OK, let's
assume you do for the sake of this discussion.)  Now, how do we code
such a tag.

The simple approach would be to try using the Java2 version of the tag,
which includes (among other things), "import java.util.Map".  How
likely is that to compile in a JDK 1.1 environment?  You've got it -- no

Well, let's just restrict things so that you have to compile Struts
under Java2, and then try to use that tag under JDK 1.1.  What happens
now?  The tag won't load, because you will get a NoClassDefFoundError
exception when the JDK 1.1 JVM tries to load classes and interfaces
that this class depends on, and does not find them.

You can write an adapter class, or you can use reflection (and pay the
performance price), but the bottom line is this -- Struts users
should view JDK 1.1 support as *temporary*, not permanent.  Therefore,
all of the "1" versions of the classes will eventually go away, and
I do not feel motivated to spend anything more than minimal effort to
support JDK 1.1 users with compatible tags in the mean time.  This is
the motivation for the "1" naming convention -- those tags are always
the JDK 1.1 equivalents.  By that token, "enumerate" should really
have been "iterate1" but I wasn't thinking far enough ahead at the time.

Why the emphasis on "temporary"?  Because, as I got permission to
announce on the TOMCAT-DEV mailing list, the next version of the Servlet
API (version 2.3), is currently planned to include a dependency on Java2
(JDK 1.2 or later).  Given that this is the future, and that Java2
platforms are becoming available on all reasonable platforms, my
interest in JDK 1.1 support is to give people transitional tags that are
functionally equivalent.  If you're in a Java2 world already, just
ignore the JDK 1.1 tags and they will go away.

For the record, the JDK 1.1-equivalent tags I'm talking about are:

> david

Craig McClanahan

View raw message