> 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).
Hahhh. Thanks for pointint that out. I do recall actually seeing Orion with
its own orion jsp base class. (DUH! ;)
> 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.
True, but if I wanted to make my own servlet from JSP, I could
"theoretically" do this. I mean..if I mapped *.jsp to my own servlet and
even if I didn't follow the spec by implementing the jsp interface, I could
actually make .jsp go to my servlet which I could then convert to my own
servlet class. I would have to implement code that checks if a class is
already available (time-date, size, etc checks), and use it if it exists,
otherwise convert the jsp into a servlet. This would not conform to the
spec, but I believe it might be possible to optimize a jsp page even more
so. Ofcourse, handling tag-libs, jsp syntax, and so on would be a pain in
the butt to implement just for a possible (not even guaranteed) improvement
in speed. I am contradicting what I said before..but when I re-read what I
wrote, I realize I wasn't exactly thinking about what I said. :)
> 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 :-) :-).
Hahaha..absolutely! Infact..I would really recommend Cobol and just have a
Cobol to Java compiler or something! ;)
> 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.
Agreed.
> 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.
Absolutely..couldn't agree more. What the hell was I thinking in my previous
email?!!
===========================================================================
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
