Michel Nizette

James Clarke wrote:

Well the fact that suncertify.properties is not visible anywhere, is not related to the code. I mean I know for a fact that the file is somewhere on the Vista system since previous options entered are automatically loaded, however I can't find the actual file, Ive tried browsing through the directories and also searched the entire drive. I also used the "show hidden files" and "show system files" options and still could not find.

Funny, because I recently observed something rather similar to what you describe, though in a different context. I bought a new computer with Windows Vista recently, on which I wanted to install JSwat (a Java debugger). Apparently the application is installed, but I can't actually see it anywhere using either Windows Explorer or a DOS box. I know it's on the file system, though, because if I try to install it a second time the installer complains that it's already there. Also, I found out that if I launch another Java application, I can actually see the JSwat files through a file chooser in that application. It is as if only a JVM can see those files.

--Michel.

as example: i live in belgium and if you subscribe for th scjd exam, you have to purchase the voucher for taking the written exam also

How so? I live in Belgium as well and I had no problem just purchasing the assignment.

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.

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.

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.