by Jason Hunter

Reader reaction to the article posted here two weeks ago titled, "The Problems with JSP" has been 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

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 am now."

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."

Anthony Nemmer:

"Why not just get rid of all that JSP servlet crap and use perl ? =)"

The Majority of Words

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 are dubious."

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

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."
...and...
"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' or 'beauty.'"

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

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."

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."

Dictating Style

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, etc
- 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 ASP!
http://www-uk.hpl.hp.com/people/ak/doc/trix-tr.html
This is maybe a good halfway house between a full template based system ala WebMacro and the current JSP....?"

Ray Cromwell:

"some of us like having the full power of Java available in JSP"

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?

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 support"

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?

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?

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."

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?

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 some sunlight.

This is the second in a series of articles. To be notified when new articles are added to the site, subscribe here.