JSP myths.

Since JPS’s came out as part of J2EE there have been lots of talks of how they were so ASP like and were badly designed.
But since there was not any alternative that time the Java community had to embrace it and used it. In the end JSP made into most J2EE based web applications.

Then in the last few years JSP started to get bad press again with advance of AJAX, component based frameworks like Wicket , JSF, Tapestry and with template based frameworks like Freemarker.

Most of bad press was around the difficulty to work with JSP as HTML developer, JSP containing too much Java code, JPS being difficult to debug, JSP not being suitable to develop component based web applications, JSP becoming obsolete since what was done in JSP can now be done with AJAX on client browser.

There are some valid points and I am personally not a fan of JSP either but want to get things straight and show that those issues have nothing to do with JSP, that JSP is not dead yet and can very well play nicely with other web frameworks and AJAX.

First lets go many years back and ask the question of why we needed JSP in the first place..

In web application, the browser makes a request to a remote server to get some type of a document for a given request.
The document in typical web application is a HTML text that needs to be create by server and written into a stream back to browser to render it.
This process is referred to as server side page generation.

The first Java technology which allowed us to do this was HttpServlet which programmer could extend, intercept doGet method, get OutputStream from response and write HTML code into it. This though worked but was tedious and required Java developer to create HTML or HTML developer to write Java code.
The solution to this was JSP that looked like HTML but still allowed Java code in forms of tags or scriptlets.
All the JSP was, is a text file that was converted to HttpServlet with auto generated code that would take the HTML part of JSP and convert to string that was written into response, copy raw code from scriptlets into doGet method and make appropriate method calls to tags (which were Java object).

Given the fact that JSP was a new technology, was not restrictive enough, web development was still new to many and JSP was still develop by Java developers in got misused alot and problems started to emerge giving bad myths to JSP.

Myth #1:

JSP are difficult to maintain and work by HTML developer.

Developers started to put so much Java code in JSP in form of scriptlets that it was a nightmare to maintain, debug and allow HTML developer to work with it.

Fact: JSTL tags should have been used more.
Emerging MVC web frameworks allowed to move all the scriptlets code into separate Java classes and allowed JSP to just contain HTML and some tags that would work with output of MVC controller.

Final words: Though JSP should not have provided scriptlets functionality in the first place, this is mainly the issue with developers who were not capable or lazy to understand JSP architecture and keeping appropriate logic in the right places.

Myth #2:

The JSTL tags were difficult to learn and use with complex data structures.
They also were difficult to work with for HTML developers.

Fact: That can be true with any non JSP templating framework out there. They all have custom tags that are not HTML specific and require some learning. They all can be misused and become complex and hard to understand.
The solution is to keep things simple, do all non display/formatting logic in separate Java controller class and output data structure that is easy to work with in JSTL.
For example instead of making JSP work with domain or DAO entity objects directly, have the Java controller create JSTL friendly object out of domain or DAO entity object and pass it to JSP. Actually this the whole point of MVC2.

The formatting can either be done in Java controller or as a Tag. I suggest to do it in Tag, since the controller’s job is to prepare that JSTL friendly object (which is actually the MVC “model”) and not how to format it. You can use JSTL formatting tags which will cover most of your needs or write one yourself and its not that hard to do.

Final words: JSP is just a technology with set of functionalities that developer can use. These functionalities can be either used properly or badly misused. The reason JSP is suffering from this is that it has been around longest and has been unfortunate to be the first to get bad reputation from developers incompetence. I am sure if other frameworks were around that long they would have had the same “image” issue.

Myth #3:

Description: Its difficult to debug JSP.

Fact: If you keep your JSP to mostly contain HTML then there is nothing to debug in here.
Most of debugging will happen in Java controller to make sure appropriate “model” is passed to JSP and in Tags to make sure appropriate “model” is received from the controller.

The biggest problem with debugging is the need to access HttpServletRequest attributes and making sure the right “model” is put into the request from controller.
In 99% of time you dont need to do this since the framework should take care of this unless you made your application so complex that something, somewhere changes your model or does redirect to JSP instead of forward. In case that you still want to check HttpServletRequest attributes you can put breakpoint in JSP directly and access HttpServlerRequest.

Final words: Minimize your application complexity. Keep things simple. Dont put abstraction on top of another abstraction and then cry foul that JSP makes it difficult to debug your mess. Many can write code but few can write simple code that does the job.

Myth #4:

You need to recompile JSP to test new changes.

Fact: Tomcat and most other servlet container support reloading of JSP when its updated without requiring full redeploy of web application.

Myth #5:

You cant reuse JSP fragment the way you can with component based frameworks such as Wicket or JSF.

Fact: Not true at all. You can have JSP import another JSP using “import” tag. This is not some seldom used feature.

Myth #6:

AJAX along with webservices like REST with JSON will make JSP almost obsolete.

Fact: These are two different technologies. AJAX is just a javascript and is a client side code that is running inside browser and can make request to server side for additional data.

In the beginning of the article I mentioned that browser makes request to get HTML document from server side before it can run AJAX code contained in that HTML.
This server side page generation is what JSP is for. Its used to generate HTML along with AJAX javascript in it.
The only reason JSP use is minimized in this case is that AJAX allows us not to have too many request to server for new page generation. But this is no way a problem with JSP and has same impact to any other server side View technologies including JSF, Wicket, PHP and so on.
You can totally eliminate JSP (or JSF, Wicket PHP for that matter) role in here by having pure HTML files with AJAX in them and have them serve by Apache.
This certainly works and might be where things are heading but in most serious applications you need to access to back end services such as security or data preloading during page generation.
Also since AJAX is running asynchronously while page is rendered you need to make sure that rendered HTML wont be broken while AJAX is loading the data it needs. This problem is usually handled by server side data preloading and HTML page preparation which is difficult to achieve with pure HTML file.

Myth #7:

PHP is better and more easy to work with than JSP.

Fact: I still cant see why? Actually not too long ago the the industry was singing the opposite tune.
JSP can easily do anything PHP can and more.
Additionally it can easily integrate with Java backend and does not require remote communication to it like PHP does.
This is more important when you need to access Java backend services such security, internalization or beans in Spring context.

Leave a Reply

  

  

  


nine × = 9

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>