Rationale for JSP deployment method

[Michel Nizette]

Hi there,

I'm learning Servlets and JSP using the Head First book (great book, by the way), and there's something I've been increasingly curious about for a while as I have been reading through.

Basically, what is the reason that led the designers of the JSP specification to decide that JSPs should be compiled at deployment time, rather than together with the other classes of the application? I assume that there must have been a very good reason for such an unusual design choice, but so far I can't clearly see the benefit of that strategy. I understand that it's the only way the JSP classes can be Container-vendor-specific, but why was that a requirement to begin with? Usual Servlets work just fine without being vendor-specific, so what JSP functionality would be lost if the base JSP class were part of a standard API and could be compiled before deployment?

It's entirely possible that I'll learn the deep reasons as I progress through the book -- it's just that I feel like I'm missing an important piece of understanding, so I can't wait anymore!

Thanks to anyone who can clarify that for me, or provide me with a pointer to the relevant info!

Best regards,
--Michel Nizette.

[Bear Bibeault]

Usual Servlets work just fine without being vendor-specific

Not so fast! Who do you think implements HttpServlet? HttpSession? HttpServletRequest? And all the other classes that are used by servlets?

Even though the API is coderanch, the implementation of that API is vendor-specific.

Same with JSPs, As long as the vendors follow the "rules" set out in the JSP Specification, they are free to implement the JSP engine in whatever manner they find appropriate.

[Deepak Bala]

Also, the JSP files can be compiled before the conatiner recieves a request for them at all. Most containers support this. These pre compiled JSP classes will give better performance on their first invocation against those that are compiled just in time.

[Bear Bibeault]

John, please contact me via email at your earliest convenience.

[Michel Nizette]

Bear Bibeault wrote:

>Usual Servlets work just fine without being vendor-specific

Not so fast! Who do you think implements HttpServlet? HttpSession? HttpServletRequest? And all the other classes that are used by servlets?

Even though the API is coderanch, the implementation of that API is vendor-specific.

Right, it is. But even so, my point is this: what is the reason why JSPs weren't designed to work the same way as usual servlets? I mean, it is clear that a JSP is not Java code, so it needs to be translated to Java code before it can be compiled. But why isn't the translation step designed to target a public API, so that the translation and compilation can be done *before* deployment, as for any other servlet?

John Meyers wrote:

Also, the JSP files can be compiled before the conatiner recieves a request for them at all. Most containers support this. These pre compiled JSP classes will give better performance on their first invocation against those that are compiled just in time.

I understand this, so clearly the need to translate and compile JSPs after deployment won't be a performance issue. No, I'm just curious as to why it had to be like that. To me, compilation after deployment means that some coding bugs aren't going to be caught as early as they could have been otherwise, so it doesn't seem like a decision that the JSP spec designers could have taken without an afterthought if there wasn't a very compelling reason for it. In my (greenhorn's) view, however, the only fundamental difference between a JSP and another servlet is that a JSP isn't written in plain Java, and I don't see how that alone justifies translation and compilation before deployment. So, I assume there must be a more fundamental reason for that, which so far remains mysterious to me.

--Michel.

[Bear Bibeault]

The fact that JSPs are turned into servlets is not part of its public API and is considered part of the implementation details. That part is up to the container vendors. This gives the vendors lots of leeway in how they accomplish this.

You could argue that the vendors could all be forced to use the same internal implementation details, but I'd say that the JSP Specification is complicated enough without getting into specifying how the behind-the-scenes stuff should work.

[Jeanne Boyarsky]

JSPs are supposed to be writeable by someone who isn't a Java developer. I bet this has something to do with why JSPs aren't compiled with the code.

[Michel Nizette]

Bear Bibeault wrote:
The fact that JSPs are turned into servlets is not part of its public API and is considered part of the implementation details. That part is up to the container vendors. This gives the vendors lots of leeway in how they accomplish this.

Now that makes sense. If how the HTML pages returned to the browser are created from the corresponding JSPs isn't part of the public specification, then clearly the only option is to bundle the source JSP files together with the other webapp files and let the Container do whatever it wants with them. I guess this answers my question. Thanks a lot!

--Michel.