The first point: Standards

One of the touted advantages of JSP is that it is a "standard" and quite a few people like to hold this in high regard. So much so that they refuse to use any technology that is not "standard." Digging into the reality of this statement reveals that the important correct terminology is that JSP is a "Sun Standard Specification" and not strictly a "standard." This is important because JSP is really no more "standard" than Microsoft ASP or the PHP Group's PHP product. In other words, whatever tool you happen to be using becomes the "standard." A small group within the Java Community Process (JCP) defines what JSP is. The fact of the matter is that there is a fairly high barrier to joining the JCP because an NDA must be signed, the project leads must approve your entry and in some cases a fee must be paid. One could even stretch as far as to say that the JSP specification is really a proprietary product of Sun! It is important to note at this point that the primary author of this document (Jon Stevens) is a member of the JSR-053 which defines the Servlet and JSP specification's. Inside JSR-053, it is clear that not everything is done in the open and decisions are made behind closed doors. Of course the participants could object, but Sun still is the binding force behind the decisions.

The next point: Complexity

JSP is both a specification as well as an implementation. There are various corporations (as well as Open Source) implementations of the specification. The JSP specification is not a particularly easy thing to implement. There are many complex systems involved, some of which even require special hooks into the Servlet Engine in order to obtain optimal performance. The JSP specification is relatively new (it is still in a 1.x phase). This means that the specification also has several places in it that are not as well defined as others, leaving some of the specific details to be determined by the implementation. Not only does this mean that there is plenty of places to make mistakes, but it also means that JSP template code has the possibility of not behaving the same across implementations. This makes testing JSP based applications a nightmare. Part of the founding reason for creating the Jakarta Project and having Sun release the source code to Jasper (the JSP reference implementation) is to encourage vendors to adopt a single base for their source code. Unfortunately, this has not happened. There is compatibility testing suites available, however there is no policy in place requiring vendors to pass the tests. Nor is there a place that shows vendors who do not pass the tests in order to publicly humiliate them into submission.

The final point: Velocity

Even though Velocity is lacking a formal specification document (it is on the TODO list and volunteers are welcome to help out) and is not a "Sun Specification Standard", that should not stop anyone from using it in production environments. The reason is that, as shown above, is that JSP is no more of a "standard" than anything else. Velocity is actually a more reliable implementation than JSP because there is currently only one implementation. Even if there were more implementations the modifications to all aspects of the Velocity project are discussed in the open (anyone is welcome to participate) and the testing suite is strictly maintained.

You make the decision.

[ Embedded Usage <- Previous | Next -> Hosting ]