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 w开发者_Go百科ould be greatly appreciated!

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.)

Most enterprise solutions would be intranets or extranets and would not be exposed to the public, so you would not know about them.

All this tells you is that you have not seen relatively many public websites written with jsp.

JSP has disadvantages, especially with JSF. With the latest version of Java EE it is recommended to use facelets with JSF instead of JSP (and a frequent suffix for this is .jsf). Another frequent framework is Struts which use .do as suffix.

Where JSP pages are used directly, they are often mapped to URLs in a deployment descriptor, hiding that implementation detail of the web application - so you might not be able to tell that it was a Java EE-based web application.

(As requested) For example, I might write a JSP page and save in my web application as /mypage.jsp. I could then define a mapping from the (arbitrary) URL /action.do to that JSP page in my deployment descriptor (web.xml) as follows:

<servlet>
  <servlet-name>mypage</servlet-name>
  <jsp-page>/mypage.jsp</jsp-page>
</servlet>

<servlet-mapping>
  <servlet-name>mypage</servlet-name>
  <url-pattern>/action.do</url-pattern>
</servlet-mapping>

In addition, developers writing Java-based web applications use a Model-View-Controller design in which requests are routed to Controller servlets that do the heavy lifting (validating request parameters, interacting with other code and services) before dispatching to a JSP to create the response (view) the user will receive. Thus, the incoming request is mapped to the servlet, not the JSP directly. The official Sun Certified Web Component Developer qualification promotes this approach, and web frameworks like Struts and JSF are built on this approach.

Java web development good practice generally means not exposing JSP pages directly, but rather using them as a view layer underlying the MVC pattern, in an arrangement in which they are only accessed from the controller.

The resulting URLs are therefore pretty generic, giving little clue as to what lies beneath.