Zarar Siddiqi's Blog

Are JSPs dead?

That’s supposed to be a rhetorical question, of course they’re dead. They died a long time ago when it dawned on us that they were nothing but untestable, overweight slobs that only ever existed because of ASP. Anybody who ever used JSPs has at some point, sworn by them, marveled at how great they are and felt really, really excited to write actual Java code inside pages. But it was only a matter of time until some of the lesser known facts about JSPs became more and more prevalent to the point of that templating languages were forced into creation to combat the shortcomings of Java Server Pages.

JSPs are the ultimate contradiction to Java reusability, there is simply no mechanism in J2EE which allows even an honest man to reuse a JSP. If you’re thinking of <jsp:include>, you’re missing the larger point of reuse - reuse as in other components of the application or even different applications. Of course being confined to a Servlet container kills off any chance of reuse in the SE world along with making testing so hard that you’re forced to mock an application server just to see what’s rendered. The direct binding to a Servlet is also something that never amused me nor did I find the behind the scenes conversion from JSP to Java to Class file ever a needed exercise. Why bother with an extra compilation stage when you’re already serving your page from a compiled Servlet?

Be advised that if you’re still considering using JSPs as the V part in MVC for even a mid-sized application, you’re making a mistake. This is especially true if you’re using JSPs as purely a view mechanism (no actual code in the pages but just taglibs) since you’re not even taking “advantage” of the ability to write Java code in them. If you are one of those folks who thinks the library wasn’t the ultimate example of bad ideas, you might actually still be using scriptlets in your pages and passing them off as acceptable software. You, you just keep doing what you’re doing, there’s no help for you.

Not too long ago a colleague of mine stumbled upon a major bank website (TD Canada Trust) who had managed to seriously screw up their application server configuration and ended up serving the raw JSP page instead of actually executing the code in it. Needless to say the code looked like crap with request.getParameter() being used more often than white space to compute user states in a banking application. It was one of those “this page can do a lot of stuff so I’ll just write a lot of ifs to figure stuff out” type things. What I’m trying to say is that JSPs promote shoving control logic in your pages no matter who you are simply because it’s so easy to fall into the pitfall that are scriptlets. It’s best to eliminate the temptation and use a dumb templating tool to render your views because let’s face it, they’re views!

What to use if not JSPs? Plenty of choices including Velocity, Jamon, Freemarker, StringTemplate, JByte etc. All good options with Freemarker being my favorite because of it’s lightweight nature, templating prowess and out-of-the-box support for Taglibs. Whether you’re templating a simple email to be sent out or a full-fledged page, the concept remains the same. Add in very easy Struts 2 integration for both Velocity and Freemarker and there’s little reason to rely on JSPs to do anything.

I used Selenium as a functional testing tool and realized that I was falling into the pitfall of checking the content displayed on the page to test whether the correct business logic was being performed rather than whether the correct view was being returned (think about it, there’s a difference). If you use a templating engine other than JSP, you can quite easily test the former without having to resorting to a functional testing tool.

As AJAX is becoming more and more popular, JSPs are getting further phased out. Lot of developers prefer to return chunks of HTML from the server rather than an actual dispatched forward. A lightweight and powerful template language is much more suitable here as your AJAX interface view will be an aggregation of snippets of HTML returned from the server. Doing this using JSPs would add a level of complexity that is both undesired and unneeded.

Having said all that, you can produce the same product with both JSPs and other lightweight template engines, but the latter stay much truer to the MVC philosophy and result in a much cleaner code base.

Comments

• You lost me at the third "shit".

  Posted by: kirillcool on April 18, 2007 at 09:41 AM

• Forgot this was java.net. Cleaned it up.

  Posted by: zarar on April 18, 2007 at 09:49 AM

• Sure they're not a good tool for a major site, but sometimes they are a really good stop-gap to getting things done... Dead is a strong word... And to say they are dead is over-egging the pudding imho. They have a place...

  Posted by: timyates on April 18, 2007 at 10:10 AM

• 
  Hmm...no.

  JSPs are alive and well.

  
  FreeMarker certainly seems to have its charms (5 minute skim, no direct experience), but that hardly kills JSPs.

  
  JSP 2.0, with JSTL and JSP Tag files, is quite usable and productive. JSTL is a perfectly usable expression language, and JSP Tag files make refactoring content and introducing custom behavior at the page level down right trivial. For generic applications with a plethora of basically static pages, there's nothing spectacularly wrong with JSPs.

  
  The pre-compiling is perhaps the biggest complaint, especially if you have a slow JSP compiler, but it's not crippling, it doesn't affect deployed applications at all, and as a developer you don't have to manage the JSP page lifecycle yourself -- the container does it for you.

  
  I also use JSP pages for Ajax renderings. Works great.

  
  For a more dynamic application, where templates as well as data are stored in a DB, JSP isn't really a good fit. But most folks don't write those applications.

  
  Finally, JSPs give users a direct path from writing horrible Java mixed in with HTML Model 1 all the way up to more advanced architectures.

  
  If you're just starting out and want Something out of your web app quickly, JSPs give you that right away, out of the box. You can write your quick hack in JSP, refactor it out later in to Tag files, Servlets, and Java Beans, and eventually migrate to a controller framework.

  
  So, it's a good crossover from perhaps the PHP camp supporting similar idioms while not limiting you to only those idioms, as the entire Java world is always there lurking in the background.

  
  I'm a big fan of JSP and I think they have a lot of life left in them and provide a good value to the community in the large.

  
  To quote Monty Python "I'm not dead yet! I'm getting better!".
  

  Posted by: whartung on April 18, 2007 at 11:28 AM

• I saw through them right from the start. OK, you do have possibilities to use them better than ASP, but it was still a bad idea to start off with.

  For outline of another alternative, see http://tobe.homelinux.net/weffo , allows you to work with the view completely separate from all the rest and open it directly in the browser.
  

  Posted by: tobega on April 18, 2007 at 03:23 PM

• I completely disagree. JSP is an appropriate tool for creating declarative code, think HTML. Ajax doesn’t mean JavaScript has to be used for everything. I am a committer on an Apache Project called XAP, which is a declarative engine for creating Ajax applications. Developers use tags like, “button”, “tabPane”, “window”, which the client loads, parses and renders. Being a client-side engine allows developers to use what ever Web framework that they know or is best for their application. This is contrary to things like JSF and jMaki which are server-side frameworks and require that framework to work. HTML and the web is where it is at because of the client-side architecture. For more information on the Apache XAP project goto http://incubator.apache.org/xap

  Posted by: bbuffone on April 18, 2007 at 08:03 PM

• When David Geary and myself wrote the first edition of Core JSF, I was adamant that we do not follow the "let's relive the mistakes of the past" approach that drags the poor readers through servlets and JSPs before getting to the good stuff. The reviewers were aghast, but we never got a single complaint from readers.
  There may be a niche for JSPs somewhere, but today there is a huge spectrum of better choices for most projects.

  Posted by: cayhorstmann on April 18, 2007 at 10:08 PM

• what's with the 'dead' postings of late. There's a similar post on the xslt big-list asking if XSLT was dead. I thought JSP are reincarnated as JSP 2.0 so it works well with JSF unlike JSP 1.1 which simply didn't agree with JSF. Agreed, Facelets is a popular alternative but if you ask me JSP is too well entrenched to die so easily. http://ovisvana.blogspot.com

  Posted by: ovisvana on April 18, 2007 at 10:58 PM

• how about some concrete data to back this up? we use jsps just fine. it's a standard available technology, it provides facilities for proper expansion via java, and gives you a great deal of flexibility you typically end up not needing. The nice part is it's there if you need it. You can even abstract out scriptlets into easy .tag files if you're occasionally lazy. I actually like working with it a lot.
  

  Posted by: ilazarte on April 19, 2007 at 12:00 AM

• This is quite pathetic to be blunt. Just because JSPs don't fit into your world does not make them "dead". Jeez, when will people learn that this is not a one size fits all world and for some of folks, JSPs are quite useful and they can actually be used well. I see no evidence from you that they are dead.

  We use .tag files a lot within our site because they are incredibly easy to modularize our pages. You can specify required parameters (now, I would love default values for attributes, however), their type and so forth.

  Regardless of the technology used if you don't follow conventions or make up conventions for your group the quality of your code is going to go into the toilet rather soon. Blaming JSPs for bad code is just ignorant. I can show you plenty crappy freemarker, velocity and Jamon code. I can show you bad Java code. I can show you a LOT of bad C++ code. :)

  Lighten up with the inflammatory rhetoric.
  

  Posted by: mbosch on April 19, 2007 at 01:32 AM

• Everything we (human being) do, we can do well or screw it up. Coding is not different, it doesnt matter if you are coding in VB or assembly. if you are good on it you will write good vb or assembly code, if you are not,....shame on you.

  Posted by: cax on April 19, 2007 at 05:49 AM

• Screws not compatible with nails. Carpenter blames hammer.

  Posted by: janerik on April 19, 2007 at 07:19 AM

• dude if they are dead why do people still using them? they are only dead when people stop using them...i think there is nothing wrong in JSP being a V component in MVC. i prefer JSP because i can use Java coding for manipulating my view logic.

  Posted by: aizul on April 19, 2007 at 08:18 AM

• " Add in very easy Struts 2 integration for both Velocity and Freemarker and there’s little reason to rely on JSPs to do anything."

  Pooping on JSP and promoting Struts... interesting.

  The tool support for JSP, JSTL and EL is too good to pass up... these templating languages have their place, but I don't think they can replace JSP for quickly getting stuff up and running... tag dirs... jstl... EL... JSP is looking better than ever... even in AJAX land.

  Posted by: chowda on April 19, 2007 at 10:36 AM

• We're using JSP as the V in Spring MVC with DWR and are quite happy with them..

  Posted by: xmaniac on April 19, 2007 at 11:32 AM

• As long as there are designers creating look and feels of sites (Read doing HTML/CSS), and they need developers to build functionality into these HTML skeletons, the JSP technology will have breath.

  A lot of sites even now aren't built with a toolbox of widgets, rather they're built with a photoshop blueprint. It's those custom one-offs that allow JSP's to stay around as long as they have.

  Posted by: bainfu on April 19, 2007 at 12:59 PM

• I love JSP. Specifically the JSP "document" style, and with a <scripting-invalid>true</scripting-invalid> element in the web.xml. Do the other re-invented wheels have something more reusable than a *.tagx file? Views, after all, are inherently anti–object-oriented, since they are an exposure of encapsulated state rather than a behavior. (What does all that EL do? Reference properties, i.e. not operations.)

  I guess JSPs just suit my strong, static world-view. Maybe there are some technorati out there who like the feeling of superiority being "different" from those "conventional" JSP users brings. I don't get it though.

  One area where JSP is shaky is in Eclipse. Boy, is WTP bad! However, tool support for JSP is still leagues ahead of any other templating language. IDEA support of JSP 2.0 is rock solid (of course). I'm guessing NetBean's is as well.
  

  Posted by: erickson on April 19, 2007 at 01:11 PM

• What I’m trying to say is that JSPs promote shoving control logic in your pages no matter who you are simply because it’s so easy to fall into the pitfall that are scriptlets.

  That goes without saying with anything in life. I find Spring + JSPs (I like freemarker better) + taglibs is quite good.

  And can't you do all of what you're complaining about in freemarker as well?

  Posted by: cwilkes on April 19, 2007 at 02:30 PM

• I'd say that with the advent of component-based web technologies like JSF, Tapestry, or Wicket (my personal favorite) it seems pretty clear to me that JSP's are an outdated and less efficient technology that's destined to start to slide into disuse over the next few years.

  Will people still use it? Sure. Hell - people still use Assembler and COBOL. But I see it on its way towards being a fringe technology soon. It was good for its time (and better than what came before it - namely servlets using printlns to output HTML strings) but there's just simply better tools out there now.

  Posted by: darose on April 19, 2007 at 03:19 PM

• I agree with the sentiment to a certain extent. If you were to say that JSPs are/were a bad idea, that would be true. As for whether they are 'dead' or not, I think there are way too many frameworks (Struts, SpringMVC, JSF) using them as their central view mechanism to say that they are dead.

  I would agree on the inheritance aspect of their being a bad idea. I find there is some really interesting things that can be done with Servlets because they are 'proper' classes. A lot of the stuff that the aspects people would say 'oh, that is a cross cutting concern' is easy to do with inheritance. Things like enforcing idempotency rules (eg: getters don't change the application state, only posts change the application state).

  As for Ajax, I think you are wrong. If you are returning a chunk of HTML, use a JSP. If you are returning a chunk of HTML with a little bit of logic in it, use a JSP. If you have a really heavy use of logic and end up returning a chunk of HTML... use a servlet and then forward to a JSP.

  Web testability especially 'unit testing' is a joke in all the popular forms. There is simply no substitute for eyeballing the result.

  Posted by: rickcarson on April 19, 2007 at 04:28 PM

• returning chunks of html isn't counter to using JSP. In fact JSPs are quite good at it.
  Scriptlets are a bad idea and should never have been invented, but sadly they are and even worse a lot of kids are still learning that they're the way to use JSP.
  That however doesn't mean JSP is "bad" or "dead", it is merely another symptom of an education system that's unwilling and/or incapable of teaching students skills that are anywhere near the current state of technology.
  And yes, I use JSPs nearly every day (some days I don't come near a computer, so not every day). I may not write them every day, and most of their URLs don't end in ".jsp", but they're JSPs.

  Posted by: jwenting on April 20, 2007 at 05:56 AM

• Um.. i find it VERY unlikely that you saw the source code of the banks website. Lets face it if they did have a configuration error you would get be getting error messages NOT their JSP source code.

  Java.net is about technical discussions.. not blanted trolling.

  Posted by: jmguillemette on April 20, 2007 at 07:03 AM

• Well this is interesting... my company created a mandate that starting 2007 all of our .NET development must be moved to Java because its "better" and more effective to enterprise development.

  I am behind this effort but as of late, all I keep seeing is articles and postings on how many of the core components of Java are dead or their use is decreasing at numbers of 7% in 2006 alone...(sdtimes.com). I also continue to run into so call Java sites but once I look at them closely some of them have not had any postings or new information in a few months or even years.

  This makes me think that perhaps a better question is Java as a whole dying and a horrible death at that? Has the Java community effort become so convoluted that even among its mists instead of technology evangelists they now have apocalyptic evangelists with tales of a horrible death?

  While I hava spent most of my time as a Microsoft developer, I believe a software engineer can be a good software engineer regardless of the language or technology use as the principals of software engineering remain the same, I also believe Java is a great technology but items like these are discoureging never the less....

  Posted by: agrodrig on April 21, 2007 at 08:10 PM

• agrodrig, your company made the right decision. This is just a debate on which view technology to use. It has nothing to do at all with the demise (sounds almost foolish) of Java. JSPs work in some cases and in others they don't. That's the good part of Java/JEE, you have choice.

  Posted by: zarar on April 22, 2007 at 07:29 AM

• 
  umm.. jmguillemette. Since you're accusing
  the OP of trolling, let me jump in here and explain that it was me who saw the JSP source code on the bank's website.

  
  Before you accuse people of blanted [sic] trolling, you might consider that even in the hugely popular Tomcat servlet container, not too long ago, several source exposure vulenrabilities existed. (Certainly in the same time frame as when I saw the JSP code). And before you respond with "oh... why would a bank use Tomcat?", let me ask you why would a bank use code that looked like spaghetti (scriptlets and all). It was so bad that it shook my faith about even bothering with MVC in a project that I was about to start just then.

  
  So there...
  

  Posted by: haroonrafique on April 22, 2007 at 03:22 PM

• jmguillemette,

  Not so. If a web server's MIME types are mashed such that files with a .jsp extension are to be treated in the same manner as files with an .html, .htm or .txt extension then the contents of the file will be piped at the browser without passing through compilation or attempting to grab the compiled Servlet.

  .jsp pages may be decreasing in their prevalence on the web, but I suspect that as long as dev houses have a requirement to quickly and dirtily get jobs out of the door as fast as possible they’ll be in use.

  Realistically, for many developers there is no shorter path in man hours than hacking a .jsp page.

  Posted by: twitch on April 24, 2007 at 07:01 AM

• If we look at the JSP as such we see a template engine. It purpose was mainly to have Java and HTML interlacing in one source for reader-developer convenience. I agree it is HORRIBLY outdated.

  The only alternative to JSP, an exact alternative that does not through away the initial idea but rather resolves the promise of JSP a better way is the so called "HybridJava" approach (rather new thing). See:

  http://www.HybridServerPages.com

  Posted by: nbs51 on May 14, 2007 at 11:39 AM

• JSP's are definitely bad, but recently when I tried to find an alternate V in the MVC paradigm I came across many solutions which do the entire MVC but not just the V. The closest I've come to what I'm after is a JSP Tiles combination, but Tiles itself seems to be getting quite out dated. I would move onto JSF, but it too seems to take control of whole MVC layer... I just want a View technology. Using JSF would mean rebuilding the model and controller parts of my application, currently done in Spring Web Flow (SWF). The other option I've got for integration with JSF would be turning off most of the functionality of JSF and going down the lightly trodden path of JSF and SWF integration.

  So despite their ills, I'm going to keep using JSPs... for now... but I'd like to see something better. And no, not Wicket... it needs to be integrated inside Spring, call me an old fuddy, but any middleware which integrates the bulk of the framework (takes on the role of Spring by containing Spring) is not okay in my book.

  Posted by: shizbot on June 07, 2007 at 07:33 PM

• HybridServerPages === V

  Posted by: nbs51 on June 10, 2007 at 12:32 AM

• Wicket needs to be integrated with Spring? Nah, it doesn't. I have no idea why you think that :) Wicket stands on its own, and using it pretty much comes down to plain Java programming.

  Posted by: eelco12 on June 25, 2007 at 05:34 PM

• I'm so grateful for all that you've done. Thanks again for that nice essay and I would be most grateful if you would send me the latter ones....

  
  mirc
  mırc
  mirç
  mırç
  mirc indir
  chat yap
  islami sohbet
  dini sohbet
  kelebek
  kelebek sohbet
  kelebek mirc
  kameralı mirc
  kameralı sohbet
  chat yap
  çet
  çet odaları
  sohbet kanalları
  sohbet odaları
  yarışma
  sevgili
  arkadaş
  arkadaş ara
  arkadaşlık

  Posted by: jklmno on June 19, 2008 at 09:19 AM

This work is licensed under a Creative Commons License.