Question

I’ve read lot of articles saying, that Java EE is most popular enterprise solution nowadays. Let’s not argue if it is most popular or second most popular or what.

The thing is: I see almost all web pages with an extension like .html, .php and .aspx.
Why there is (almost) none .JSP ?
Why is it so easy to find ASP.NET pages if it is supposed to be less popular?

Please I am not programming with Java EE (yet) so don’t blame me, if I am completely wrong. The answer with patience would be greatly appreciated!

Answer 1

The most common answer to why you don’t see .jsp extensions in URLs is because (at least with well-developed Java EE sites) is that JSP pages are never accessed directly. They form templates or extension points associated to URIs and resolved by some form of controller or filter.

It used to be the case in the early years (pre-serlvlet era) that you would publish JSP-suffixed URLs, but no more.

The standard Java EE practice now is to

1. have all JSP files under WEB-INF
   (thus rendering them
   un-referenciable with URLs),
2. define one or more controllers that
   handles URL requests
3. define a mapping of each URL to a
   set of resources (JSP pages for
   instance)

The controller(s) then know how gather all those resources, compose them together and spit out the HTTP response for a HTTP request.

The reason to do so is to separate the URL from the actual artifacts used to make up the resource. If a user bookmarks your JSP page, you cannot move it or rename it, not unless you break his bookmark or introduce a HTTP redirection. But if you hide your JSPs, you can manage them anytime you want without breaking the URL.

It is pretty much an application of the rules of composition and encapsulation to URLs.

For example, imagine that you have a URL, /hello.

Then you have a header.jsp, a footer.jsp and a body.jsp file under WEB-INF (hidden from the public).

When you send a HTTP request for /hello, the controller behind it will do its magic, composing a HTML page using the header, footer and body jsp pages.

If you later need to add a navigation bar on the left (say navbar.jsp under WEB-INF), you configure your controller to compose a new HTML body using navbar.jsp to create the navigation bar.

You URL remains the same even though you added a new JSP file to its composition.

Another reason for doing so is information hiding and security. There is no reason to advertise to the outside world (or even users inside a corp’s intranet) about the technology behind your web application. If you let URLs have JSP suffixes, you are telling the world that Java EE is behind the scenes. Even if such knowledge poses no risk, you never want to do that.

Lastly, what happens if you ever want to change technologies, but don’t want to break existing URLs? You may have a contractual obligation to keep them alive. Divorcing URLs from technology-specific file extensions will help to do that.

Hope it helps.

— Edit —

Regarding the following statements I made:

If you later need to add a navigation bar on the left (say navbar.jsp
under WEB-INF), you configure your controller to compose a new HTML
body using navbar.jsp to create the navigation bar.

You URL remains the same even though you added a new JSP file to its
composition.

If you were referencing JSP files directly, you could still achieve the same encapsulation (of hiding the navbar change) by having the URL reference a main jsp page which composes itself with the navbar, header and footer JSP sub components. However, your URL schemas would still be coupled with the technology that powers them.

Moreover, and this is something I forgot to mention before: what happens if a user accidentally or maliciously access the footer or navbar jsp directly? That might be harmless, or it might not. It might need to be addressed, or it might not. Regardless, that is an additional variable that needs to be considered. It is another decision (among the many that will inevitably plague the design of any complex system), a decision that has to be taken, or that can be taken wrongly, or ignored by mistake (until unexpected errors happen.)

So, by hiding that behind technology-agnostic URLs, *you remove that variable, that design decision off the table*. It is one decision less to make or worry. So you can imagine this (the hiding of JSP behind agnostic URLs) as an architecture decision. And the goal of architecture is not to multiply the number of ways that we build software. Quite the opposite, its goal is to reduce it, to box the number of design decisions, to reduce the permutations and combinations in building software (ergo, minimizing the cracks from where errors creep out.)

So that would be another angle that can explain the rationale of hiding JSP pages (or any web page template technology for that matter.)