aspose file tools*
The moose likes JSP and the fly likes Rationale for JSP deployment method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSP
Bookmark "Rationale for JSP deployment method" Watch "Rationale for JSP deployment method" New topic
Author

Rationale for JSP deployment method

Michel Nizette
Greenhorn

Joined: Nov 15, 2006
Posts: 5
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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61206
    
  66

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 public, 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.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Deepak Bala
Bartender

Joined: Feb 24, 2006
Posts: 6661
    
    5

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.


SCJP 6 articles - SCJP 5/6 mock exams - More SCJP Mocks
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61206
    
  66

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

Joined: Nov 15, 2006
Posts: 5
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 public, 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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61206
    
  66

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
internet detective
Marshal

Joined: May 26, 2003
Posts: 30516
    
150

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Michel Nizette
Greenhorn

Joined: Nov 15, 2006
Posts: 5
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Rationale for JSP deployment method