Petr Jiricka wrote:
> Hello, I have two questions about the servlets which are generated from JSPs
> in JSWDK 1.0.
>
> First, why does the compiler generate new names for source files each time a
> JSP is reloaded (files nameofthejsp_jsp_x.java) ? It seems that the runtime
> system shouldn't be dependent on these files, so it is an internal issue of
> the compiler. Would it matter if the file was just nameofthejsp.java ? I
> thought that it could be an issue with class reloading, but the class files
> have always the same name, and class reloading shouldn't be much more
> difficult than just throwing away the classloader.
>
This is probably done to simplify the auto-reloading feature when you change a JSP
page, so that the implementation does not need to play games with class loaders.
Having written a servlet engine implementation (I'm involved in the Apache JServ
project), I can tell you that much magic and hand waving is needed to deal with
this.
Just as an example, throwing away a class loader throws away all the objects you
created with it. What if you wanted your sessons to survive a JSP page reload,
but you used the old class loader to stash a bean there? Now, if you reference it
from the JSP page using the version of the class loaded by the new class loader,
you get class cast exceptions, even though the name of the class is the same!
All in all, it looks like they took an easier path, by creating uniquely named
classes each time. As you point out, it's an internal issue, and users are not in
fact dependent on the names being created. The JSP servlet always resolves the
name of the JSP page to the "current" class for that page. This is also explictly
allows for in the specification.
>
> My second question is about classes importing com.sun.jsp.runtime.* classes
> to generated servlets. I heard that there are plans for the next version of
> the specification to define distributable archives of precompiled JSPs. This
> means that in order to achieve platform independence, the
> com.sun.jsp.runtime.* classes should either not be used or should be freely
> distributable. What is going to be a solution to this problem ?
>
The distributable archives stuff is actually in the Servlet API 2.2 spec (now in
public review), because it applies to both servlets and JSP pages.
http://java.sun.com/products/servlet
The first level of portability needed for JSP is source-level portability of
JSP pages. That's assured as long as you do not yourself import any
engine-specific classes (like com.sun.jsp.runtime.*), and your JSP engines
correctly implement the specs.
Ideally, a JSP implementation would also generate object code (servlet class
files) that are also platform independent. In order for this to be accomplished,
the generated code should import only the standard API interfaces
(javax.servlet.jsp.*), and not the engine-specific ones. The JSWDK JSP engine
does not currently do that, so its generated classes will only run under itself.
As a practical matter, the JSWDK JSP engine is in fact going to be distributable,
because it is being given to the Jakarta project (http://jakarta.apache.org), and
will be released (I've seen repeated assurances about this) under the Apache
license, which is pretty liberal about reuse -- check www.apache.org for details.
However, as of JSP 1.1 it looks like the standard API for JSP is rich enough to
implement execution-time portability across JSP engines. I would hope we see the
JSWDK engine modified to generate portable code using these APIs soon. Then, JSP
pages would be portable across JSP runtime implementations at both the source and
executable level, just like servlets are.
>
> Thanks
>
> Petr Jiricka
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
