Why I Hate JSP

by Steven J. Owens (unless otherwise attributed)

Note: Update 2007: This was originally written somewhere around 2002 or 2003. Funnily enough, when all is said and done, though I still hate JSP, I hate it less than I hate most of the frameworks people have proposed. Taglibs looked really interesting, but I have to see somebody actually use them for something that solves a problem I care about (replacing an iterator scriptlet with an iterator tag is not something I especially care about). I have some ideas for possible uses for taglibs, but since most of the taglib development tutorials are fairly shallow, I have yet to find sufficient spare attention span to learn how to develop a taglib I would actually use.

JSP is a five year old technology, but it doesn't look as if it's significantly matured since it was introduced five years ago. I would use the old "experience" cliche of "one year of experience, repeated five times", but I don't think it's even matured that much.

JSPs in general seem very much "accident prone". I'm still struggling to articulate what exactly that means, and why it is. The ongoing results are this page.

JSP tools - JSP compiler and editor support - don't appear to have matured considerably in five years either. The JSP technology itself has numerous kludges that should have been refined out by now. Heck, I can't even find a decent auto-indenting emacs mode for JSP!

Some More Specific Complaints

All of these make troublehshooting and debugging much harder than it has to be, and any attempt to make one stage (.jsp, .java or .html) more legible makes the other stages less legible.

And this is only in the superficial sense!

Under the Hood

Besides the stupid formatting issues, JSPs produce very crudely written servlets. At the very least, there should be a java object model for the web page being assembled, to enable programmatic interaction with it. Form tags ought to compile not just to out.println() statements, but to some flavor of objects (similar to the jakarta ECS, Elements Construction Set - instantiate a form object, instantiate an input object, call form.addInput(inputobj), etc).

I generally disagree with using an object-based approach to construct HTML pages - tags are much more suited to the task, and have done well for such, even beyond the presentation/logic division. Certain types of languages are better at expressing solutions for certain problem spaces. This is just how it is. Markup languages are better for expressing presentation; regular expressions, though baroque, are better for serving their niche (though I would hope we could come up with a more accessible flavor of regexps).

However, in this case, we'd be using markup to generate an object model that then should be conducive to integrating with the rest of the application. That calls for something ECS-oriented.


One issue - and this is a bit tricky to separate from the underlying servlet and HTTP concept - is that the data types all get flattened to Strings or have to be stashed as session or request attributes and then cast back. I may not be doing it right, but so far, this has been a pain in the ass.

I guess, thinking about it, the problem is that it sort of locks you into the classical model of web applications, with parameters coming in and getting forwarded and passed around.


(previous disjointed notes on this topic)

I just finished a project, doing it pretty much in vanilla J2EE, deliberately, in an attempt to get at least one "pure" J2EE project (or as pure as possible - not much call for EJB in this one) under my belt.

I ended up building a slew of brute-force java beans, mainly by grabbing a trivial code-generator somebody'd written, and massively extending it. I have concluded that a framework of some kind should greatly improve this.

Note: Update 2007: I have also concluded that the vast majority of frameworks don't really solve the problem, but instead reinvent the problem, or make me go miles out of my way to solve less critical problems.

I've recently been reading on up JSF, and I'm beginning to have some hope that JSF may make serious improvements.

Note: Update, 2007: JSF does in fact look really neat; I found some draft chapters of the Core JSF book online and it really helped explain how it works. Unfortunately, JSF is not really a servlet/JSP framework so much as a servlet application for writing web appplications. You run the JSF application and you code your application inside JSF. Neat, and I may yet decide it's worth learning, but so far I really like the servlet API, I just want some tools to fill in the gaps without chucking out the original API.

Struts appears to be getting a lot of market play, so of course I need to add it to my repertoire, and it looks like it has lots of cool stuff. But... it's large and complex and has something of its own "way of life". Struts and Cocoon definitely look worth exploring.

Note: Update 2007: Struts definitely became a market force, but my biggest objection to it is also my most common objection to various web app frameworks; it chucks out large chunks of the servlet API.

I need something akin to the perl cookbook, only for JSP. Not to mention I need a book on "JSP for servlet developers." Or maybe "JSP for real programmers."

The JSP world suffers from the same issue the Javascript world suffers from, i.e. relatively few real programmers get really deeply into JSP (though JSP has more in the way of real programmers, probably because custom tag libs involve a real programming language, java).

JSP is not that bad an idea, but the design and implementation lack. For example, JSPs compile to servlet source. However, too much of that is brute-force. The resulting servlets are unmaintainable and difficult to interface with and or extend. Right now, I'm trying to figure out trivial stuff, like how to do the traditional menubar where the button for the current page is grayed out, etc.

I've completely given up on doing this in any semblance of right. I'm just slapping JSPs together, hoping to get something working, so I can come back later and re-do it. Sounds like any project, right? Well it shouldn't have been this way. I might as well not be using JSPs. I've ended up basically writing my servlets in JSPs.

One thought that comes to my mind is, if I were going to write a JSP compiler, I'd be writing it to use something like ELC. I can tolerate the general idea of JSPs, but the implementation sucks and is way too java-centric.

Maybe it's my perl background, but the java world in general seems unhealthily fixated on hard-coding stuff. JSP seems dynamic, but it's still fixated on hard-coding. You don't do JSPs without a lotta hard-coded messenger javabeans.

And yet, in spite of that, the JSP tag language is wholely inadequate for doing anything elegant in terms of templating.

WebMacro is on my short list of alternatives to consider.

A friend writes

From my casual inspection of the whole Java web architecture thing, it has some... um... obvious problems. It's ripe for a nice domain-specific-language to sit in the middle-to-last tier. There should be something that automates/templatizes/scripts the whole "get data from a source and build presentation logic around it".

Java is too statically-typed-BigWordsAndClassesToEnter to make it easy. What is needed is some nice language where you can, with a nice high level syntax, say:

get attributes from bean and build a presentation object.  
pass that to this xhtml formatter with parameters 
loop on this to generate pages.

Note: Update 2007: Ruby On Rails is the big fad these days; ruby looks neat and it's refreshing to talk to developers who don't hate their programming language. Rails has gained a ton of advocates, and it sounds a lot like it's side-stepped much of the cruft/admin overhead that the servlet spec 2.3 introduced along with all the neat stuff. But they also rave about "oh, it's a fundamentally new and better way of doing webapps" and I'm skeptical of that part.

See original (unformatted) article


Verification Image:
Your Email Address:
Confirm Address:
Please Post:
Copyright: By checking the "Please Post" checkbox you agree to having your feedback posted on notablog if the administrator decides it is appropriate content, and grant compilation copyright rights to the administrator.
Message Content: