Reactions to "The Problems
by Jason Hunter
Reader reaction to the article posted here two weeks ago titled,
"The Problems with JSP"
tremendous, generating around 100 messages on the public mailing
lists (jsp-interest, servlet-interest, and the official webmacro
list) and nearly another 100 more to me individually. This follow-on
article showcases some of the most interesting points made during
the discussion, for those who didn't get to read all the replies
and to make public what people sent to the feedback alias. The results
were a little surprising.
Posts were selected based on my opinion alone. Emails written
to the feedback alias by people taking the option for their correspondence
to remain confidential have not been quoted. (Too bad, there were
some good ones!)
The Majority of People
The vast majority of people responding to the article have been supportive.
Almost everyone writing appreciated the exchange of ideas fostered
by the article.
I'm slightly shocked to have received absolutely no flames, in either
public or private correspondence. The closest I got was a joke. At
least I'm taking it as a joke.
- John Keyes:
- "I thank you for making people think about the reasons why
they use certain technologies (which in a number of cases is because
its a buzzword and not for functionality)"
- Martin Jarvis:
- "How great it is to find someone else sharing my doubts about
JSP. Many of the projects I am involved in are all using servlet
based templating framework that we have developed."
- Robert Crawford:
- "Interesting article -- I happen to agree completely, though
I favor freemarker."
- Doug Dominiak:
- "I very much enjoyed your article. Well-written. I was not
aware of some of the things you mentioned, and am glad that I
- Robert Fisher:
- "I completely agree with the article "The Problems with JSP".
For a while now, I've been trying to explain to everyone I know
why JSP isn't the answer to separating code from content, but
I haven't been able to articulate it as well as the article did.
I love JSP. I think it's a great technology for those projects
in which mixing code and content makes sense. But, if separating
code and content is your goal, JSP isn't the answer."
Boy, I hope it was a joke.
- Anthony Nemmer:
- "Why not just get rid of all that JSP servlet crap and use
perl ? =)"
The Majority of Words
While the majority of people were supportive, the majority
of words (especially on the JSP mailing list) have been defending
Most of the responses have been highly focused on whether JSP or WebMacro
is superior technology. This debate misses the main question: Is it
valid for the official "Application Programming Model" document published
by Sun and a public record of Sun's philosophy to say, "JSP technology
should be viewed as the norm while the use of servlets will most likely
be the exception." (Section 1.9, December 15, 1999, Draft Release)?
That's a radical statement, and I believe that should some combination
of the servlet-based alternatives (WebMacro, FreeMarker, ECS/htmlKona,
Cocoon, XMLC, XSLT, Turbine) provide a better solution and together
garner significant market share, the statement can be determined to
- Josh Hunt
- "I just got done reading your article on the problems with
JSP. I am working on a project that makes heavy use of JSP. Although,
I can agree with some of the things in your article there are
a few that I disagree with."
- Scott Stirling
- "I got the point of the non-JSP alternatives being available
and perhaps overlooked. I also got the one that JSP shouldn't
be seen as the logical replacement for servlets. But I didn't
like some of the red herring and straw man arguments used to try
to bolster the points"
- Govind Seshadri
- "Interesting article...although I mostly disagree with the
notion that using WebMacro is a 'great leap forward' compared
to using JSPs and custom taglibs."
- Ray Cromwell
- "About the only positive thing your paper highlights is the
need for a more economical iteration mechanism for containers,
and perhaps, although it's borderline, a more economical syntax
for variable interpolation. All the other benefits you assert
- Kevin Duffey
- "Well, I dont much agree with your article, at least in the
way of a template engine being a better alternative to JSP. I
can see how in some cases it may make sense for those either too
lazy or too unwiling to understand the JSP syntax. To me, a template
engines syntax means learning a lot more than JSP syntax. Sure,
you can mistype the <%! with <%, but if you learn JSP, you'll
know when to use one or the other."
Why should we care if the statement is true or false? Because
if it's true and JSPs are the natural follow-on to servlets, then
we servlet developers can stop developing and using these alternative
content creation methods and concentrate on JSPs. However, if that
statement is false, then we should educate ourselves about what
options are available and learn where each technology performs best.
At the same time we should encourage the technologies to cross-pollinate,
using the best ideas from each.
Because I believe the APM statement to be false, I'm glad to see
the article has encouraged the debate over when JSP should be used
and when alternatives should be used. There are a lot of alternatives
to consider, as readers pointed out.
- Govind Seshadri:
- "Anyway, what is so special about WebMacro in particular? Why
not use Cocoon, Turbine, Freemarker, OTembo or even ECS? They
all offer similar features and I daresay, some of them are probably
better supported than WebMacro."
- Bill Thompson:
- "Jason, excellent wrap up of where most of us are today! I'd
like to throw into the mix another approach to generating html.
Specifically, XMLC from the enhydra project. XMLC completely separates
html from code, thus eliminating most of the problems you refer
to for both jsp and template engines."
- Stu Charlton:
- "I really agreed with Jason's conclusion on this article as
it reflects my professional experience with JSP. It winds up making
your GUI very unmaintainable unless you invest a lot of resources
in making a sophisticated infrastructure [which is what we did
eventually - mapping JSP to business objects with reflection].
I would like to say that forthcoming servlet template engines
REALLY COULD learn a lot from Apple's WebObjects. This product
still provides (since 1994) the most flexible, high-performance,
and CLEAN templating system that I've seen. It works so well that
even HTML tools like Adobe GoLive support it.."
The JSP Standard
Overall, the most compelling argument made during the post-article
discussion for why to choose JSP over WebMacro (and over all the alternatives)
has been the power of the JSP standard. A common platform that's "good
enough" generally wins over an alternative that's slightly superior;
it's something called the "Network Effect" -- the success of a component
(technology or otherwise) depends on the network of support infrastructure
established around that component. Microsoft Windows is the classic
example. VHS videotape is another.
For the counter-argument, in response to Craig...
- Ann Marie O'Meara:
- "JSPs are popular, they are widely-understood, there are nice
tools to develop them, and other people can answer questions on
them. I also do not feel that we are imposing on anyone by asking
them to learn the JSP syntax, since it seems to be the emerging
standard for server-side Java."
- Nic Ferrier:
- "I personally would not suggest using a non-standard tool for
a big rollout project that is going to need continued support
- as much as I would like to sell my clients my continued existance
to support GNU-Weblook (or whatever) I can't. But JSP is clanky,
we can improve it. We'll only do that by talking about and experimenting
with new ideas."
- Craig McClanahan:
- "If people like WebMacro, go for it ... in this particular
case, I'm going to stay mainstream on the projects I manage."
"I have to wear my 'project manager' hat as well, and say what's
best for the overall product. In many cases, that means mainstream
technology choices, quite independent of technical 'elegance'
- Robin Meade:
- "Agreed. But how does a fledgling elegant technology ever become
mainstream? Early adopters try using it, like it, and help give
it some recognition. I believe this is what Jason Hunter is doing,
and I thank him for it. Once developer interest reaches a critical
mass, the technology quickly matures and becomes maintream."
The Difficulty of Leaving a Standard
Leaving a standard can be a difficult business case. Selling people
on a technology they know nothing about is an uphill battle. For example,
some people were uncertain on the portability of WebMacro:
I found this post particularly interesting because WebMacro works
on more platforms than JSP.
- Kevin Duffey:
- "I can't say if a template engine such as WebMacro exists on
multiple platforms or not, but I would imagine JSP/JavaBeans/Java
has a much wider range of platforms and far more support in app
servers and web servers."
In the end, however, the truth doesn't matter here as much as the
perception -- JSP is a standard, managers trust using standards. You
won't get fired for using JSP.
- Jason Hunter:
- "JSP doesn't work fully in Servlet API 2.0, which is what Apache/JServ
supports. And the specific portion that's missing is the RequestDispatcher
part that allows you to do the separation discussed above. Plus,
JSP 1.1 support is very spotty and each vendor has their own bugs
you have to work around. There's something nice about WebMacro
working with the older Servlet API 2.0 and without any vendor-specific
bugs. There's just the one open source implementation to fix bugs
in. Kinda like Perl."
Because of the "network effect" around the JSP standard, JSP should
remain the dominant servlet-based technique for generating content.
However, JSP has not been widely perceived as a "sure thing", as servlets
were. I personally have never heard from anyone who learned servlets
and decided they weren't useful. Yet lots of people have used JSP
and felt it didn't satisfy.
But then, what one person would prohibit, another will depend upon.
- Geoff Soutter:
- "If someone at Sun had had their thinking hat on they could
have made a much nicer version of JSP by giving up on M$ "compatibility"
and making the following changes:
- a tag library from the start, with standard tags for looping,
- simple syntax for accessing variables, etc in HTML without resorting
to overly complex XML stylee
- NO java code allowed to be embedded in the HTML!
- avoiding "compiling" JSP pages into class files (not necessary
when no java code)
This much was obvious to me anyway 18 months(?) ago when JSP 0.90
was released: I looked at it and went: "sigh". It's weighted far
to much in favour of developers.
To my mind: it should be like so:
- JSP (or similar) is for HTML people
- Servlets / Beans are for Java developers
For those who are interested in such things: Anders Kristensen
published a paper a couple of years back that describes a JSP-alike
system which would have been a much better starting point than
This is maybe a good halfway house between a full template based
system ala WebMacro and the current JSP....?"
Perhaps the difficulty is that when you move to the "high" level of
JSP, you must start dictating architecture. Servlets are a generic
platform, a blank canvas and a set of paints. You may do with them
as you will; everyone can agree to use servlets. JSP builds an architecture
on top of servlets, and because of that dictates to some extent how
pages are created.
- Ray Cromwell:
- "some of us like having the full power of Java available in
- Runar Oli Bjarnason:
- "But that's the whole beauty of JSP. The ability to embed ANY
code directly in the HTML."
- Ray Cromwell:
- "Well, given the extreme popularity of Cold Fusion, I'd say
they would prefer the XML syntax. In fact, I know designers who
worked on both a WebMacro-like template language, and on Cold
Fusion projects, and they preferred Cold Fusion syntax."
Yet there are alternatives. WebMacro uses a style that's similar
to JSP "Model 2". ECS uses a drastically different approach creating
a page as a set of Java objects. Turbine uses a central servlet
dispatcher. Cocoon and XMLC use XML for content creation. Different
styles work better under different conditions. JSP dictates style.
Style is a dangerous thing to standardize.
Tools to the Rescue?
In response to "Problem #3: Simple Tasks are Hard", several people
pointed out that tools will make these tasks easier.
That's probably true. However, others pointed out that not everyone
(like Linux and Solaris users) will have access to or will want to
- Hans Bergsten:
- "I'm pretty sure that the majority of the web sites we see
today are developed with tools like FrontPage, NetObject Fusion,
DreamWeaver, etc. rather than by people hacking HTML in a text
editor. The custom action model lends itself very well to tool
- Robin Meade:
- "I suspect that a template tool with elegant syntax will be
favored by those who prefer using text editors over visual tools
for text markup. Programmers tend to fall into this category,
as well as a significant portion of html designers.
JSP syntax, as it stands now, IMHO, is a drag to learn, type,
and look at. Discussions like this may help expose this as a shortcoming
that could be addressed. Perhaps something like the <wm:webmacro>
tag that you suggest below.
Or maybe JSP's verbose, unsightly (IMHO) syntax will relegate
it to *only* being manipulated by tools. If so, that leaves a
sizeable niche in the server-side java community for a decent
template tool with a simple, elegant syntax."
Do We Need a Compiler?
In response to "Problem #6: Need a Compiler", a new fact came to light.
Unfortunately, for right now Tomcat has yet to bundle tools.jar, and
other servers don't yet have the same licensing agreement. Yet this
holds great promise for the future.
- Hans Bergsten:
- "Sun has allowed ASF to redistribute the javac compiler, in
a separate JAR file as opposed to the complete tools.jar."
Is Space an Issue?
In response to "Problem #7: Wasted Space" some disagreed.
And some agreed.
- Hans Bergsten:
- "Yes, the class files take up disk space. But disk is cheap,
so I don't see this as such a big deal. Regarding the difference
between memory usage between JSP and template systems, I'm not
convince the difference is so big. I assume that for a high performance
site you would end up caching all templates, which would require
roughly the same amount of memory as JSP class files. But even
if you're right, memory is also cheap."
Perhaps the issue can be declared moot if JSP implementations take
advantage of the following.
- Ethan Henry:
- "I think that the lack of class unloading/reloading is the
major factor that will keep real sites from using JSPs."
- Ray Cromwell:
- "the class file need not embed the String constant pools, but
can actually store offsets into the JSP source file, and read
them at run time. I have a hack to GNUJSP that does this. The
resulting class files are much smaller, and *do not* occupy class-heap
memory, so that with a little change, the static String data can
actually be GC'ed and re-read as needed (by using SoftReferences)"
Where are We Today?
So where are we today? Are we any better off than we were two weeks
ago before the article? I'd like to think so.
The article pointed out seven things that at least some people
believe are problems with JSP. Because of the article, some of these,
such as the memory consumption issue, have been discussed and proposals
made for how to avoid the problem with better implementations. The
open discussion has helped improve the technology.
More importantly, at least in my mind, awareness has been raised
that there are alternatives to JSP. People are downloading and trying
WebMacro. They're checking out XMLC (http://www.enhydra.org, http://staff.plugged.net.au/dwood/xmlc/index.html),
Cocoon (http://xml.apache.org/cocoon/), XSLT (http://www.xslt.com),
ECS (http://java.apache.org/ecs/), and the rest. They're looking
at JSP not as a "sure thing" servlet follow-on but as one good option.
My biggest concern has been the promotion of JSP at the expense
of the alternatives. Considering the indisputable fact that not
everyone who likes servlets likes JSP (whether or not they "should"),
I'm worried that people who are not yet in the "servlet camp" may
try JSPs, find themselves dissatisfied, and not realize that perhaps
XMLC, Cocoon, ECS, or another of the servlet-based alternatives
would work great for them.
Servlets are the common platform, like TCP/IP. JSP is likely to
become the most popular technology built on that platform, like
HTTP. But neither JSP nor HTTP works best in all situations, and
maybe not even most situations. With any luck, you the reader can
help ensure that other servlet-based technologies get a shot at
This is the second in a series of articles. To be notified when
new articles are added to the site,
Care to comment on the article? Fire an email to email@example.com.
Interesting comments may be posted unless you specify otherwise.