"Duffey, Kevin" wrote:
> Despite the fact that the spec says JSP must extend JSPServlet and all that,
> I am wondering why its not allowed for an app server to do its own thing
> with JSP pages.
They are.
The spec says that an app server can generate a class that extends whatever base
class it wants to, as long as the resulting servlet implements the
javax.servlet.jsp.JspPage *interface* (not extends the JSPServlet *base class*).
Most JSP page compilers provide a base class that is unique to that container,
optimized to make your compiled classes as small as possible (shared code appears
once in the superclass) and as fast as possible (optimized for the internal
organization of that container).
> For example, I could map *.jsp to my own servlet, which
> would then parse the JSP page, and convert it directly to a servlet..one
> that does not extend JSPServlet or whatever it is. Why is it forced to
> extend JSPServlet?
As above, it is not forced. In fact, you as a page developer have the right to
tell the JSP compiler to use your own base class, instead of its own, if you want
to:
<%@ page ... extends="com.mycompany.MyJspBaseClass" ... %>
However, you are explicitly warned that this is likely to make performance *worse*,
because the page compiler has to give up all the optimizations built in to the base
class it knows about, and write extra code in the generated servlet to make sure
your page obeys all of the rules of the spec.
> Seems to me to make it as fast as possible, it would be
> better to just directly convert the JSP page into a single servlet that
> extends nothing (if possible), and make it as lean and fast as possible. I
> don't know if there would be significant improvement in overall site speed
> because of this.
>
By this argument, we should never ever use subclasses, right? :-). I guess we all
need to go back to C programming -- this "object oriented" stuff wasn't all it was
cracked up to be :-) :-).
Seriously, whether you use subclasses or not versus implementing the same code in
every servlet has essentially no impact on performance (other than the fact that it
costs you more memory because of the code duplication). And, as we all know, if
the code is only in one place (the superclass), it only needs to be changed once
when bugs are fixed or new features are added.
The JSP spec gives container vendors quite a lot of latitude to differentiate
themselves on the generated code quality (and thererfore performance) of their JSP
implementations -- with you having a guarantee that your page will function
identically on any of them, as long as *you* obey all the spec rules. This is the
same kind of freedom you have to choose which JVM to run on. For example, try the
same application on a JDK 1.1 JVM with the JIT turned off, versus a 1.3 JVM with
HotSpot -- for many interesting classes of applications (including pretty much all
web apps that are not I/O bound), the performance difference is dramatic. And that
difference is totally due to changes in the underlying container -- not in your
code.
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
