<?xml version="1.0"?>

<!--
   Copyright 2000-2004 The Apache Software Foundation

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
-->

<document>

  <properties>
    <author email="jon@latchkey.com">Jon S. Stevens</author>
    <title>You make the decision - Implementation</title>
  </properties>

<body>

<section name="Implementation">

<subsection name="The first point: Standards">

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

<p>
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!
</p>

<p>
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.
</p>

<p>
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.
</p>
</subsection>

<subsection name="The next point: Complexity">

<p>
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.
</p>

<p>
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 across
several different containers a nightmare. Especially if there are
essoteric bugs (meaning bugs that only show up under extreme conditions)
in one and not in the other.
</p>

<p>
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.
</p>

</subsection>

<subsection name="The final point: Velocity">

<p>
The definition of what Velocity is is set forth by the developers on the
project. They have created a comprehensive testing suite that is used
for regression testing to ensure that all changes to Velocity will not
break existing templates. If you or your company ever wants to join the
development of Velocity and help determine its direction that can be
done easily by simply joining a mailing list and contributing to the
development effort. This means that no one corporation will ever own the
Velocity specification and it also means that Velocity will always work
with your templates within any servlet engine.
</p>

</subsection>

<p>
You make the decision.
</p>

<p>
<strong>[ <a href="ymtd-embedded.html">Embedded Usage</a> &lt;- Previous | 
    Next -&gt; <a href="./ymtd-hosting.html">Hosting</a> ]
</strong></p>

</section>

</body>
</document>
