This is also called JSP.

Note that "Java" and "Server" are melded together into a single, gruesomely-capitalized word by the awesome power of the Twin Gods of the New Economy (RIP): Marketing and Intellectual Property Law (you can't trademark a word that anybody with any self-respect would ever use: It's got to be some kind of annoying neologism).

At a glance, JSPs look a lot like Microsoft's ASP or PHP1: It's essentially an HTML page with code embedded in it. The code generates parts of the page. In response to a client request for the page, the web server executes the code. The code can do anything it likes. It talks to the outside world -- databases, for example -- by varying means. ASP lets a page instantiate COM objects; JSP lets you instantiate arbitrary Java classes and Java Beans. I don't know what PHP does for that sort of thing.

The advantage of all of this is that it's easier and more pleasant to embed code in an HTML file than it is to write a program which generates all of the HTML. In the latter case, you have to write a lot of print statements with quoted HTML, or some such thing. Typing "print" and putting quotation marks around lines of text is the kind of mindless work that computers are good at. That's what we're doing here: Dumping some tedious drone-work on the computer.

The three differ in varying ways, too: ASP lets you write the embedded code in any of a number of languages (VBScript, JavaScript, Perl, Python, or anything else for which the server has an Active Scripting Host interpreter installed). JSP gives you a choice of Java or Java (though there is a language directive, which implies a choice of languages is at least conceivable), and PHP seems to have its own language. I will make no further attempt to discuss PHP, because I've never used it.

(The Everything Engine (you're soaking in it!) has a lot in common with this stuff, too, by the way.)

Here's an example:

<%@ page language="Java" contentType="text/html"%>

<html>
<head>
    <title>JSP Example</title>
</head>

<body>

<%
    String foo = "foo foo";
    //  out.write() is our "print" function.
    out.write( foo );
%>

</body>
</html>

The way this all works is that the server takes the page and turns it inside out, so to speak: The .jsp file is read and divided up into HTML bits, and Java bits. The Java code is left as it is, and the HTML code is inserted into out.write() statements. This is then stored in a file, which is handed over to the Java compiler. Here's a simplified view of what that file might look like for the above .jsp example. Note that the Java code inside the <% / %> block is not printed. Instead, it gets executed.

    out.write( "<html>\n" );
    out.write( "<head>\n" );
    out.write( "    <title>JSP Example</title>\n" );
    out.write( "</head>\n" );
    out.write( "\n" );
    out.write( "<body>\n" );
    out.write( "\n" );

    String foo = "foo foo";
    out.write( foo );

    out.write( "\n" );
    out.write( "</body>\n" );
    out.write( "</html>\n" );

The compiled .class file is saved for later: The first time a JSP page is requested is a bit slow, because the page has to be compiled first. Second and subsequent requests are much faster, up until you change the file. If it's been changed since the last compile, naturally it has to be parsed and compiled again.

This is exactly the way ASP does it, except that there's no compile step because all of the languages ASP uses are conventional scripting languages, interpreted at run time. 2

There is one further convenience. It goes like this (and you can do the same in ASP):

    <%= foo %>

That's shorthand for <%out.write( foo )%>; (or in the case of ASP, <%Response.Write( foo )%>;).

Once you understand how the page is processed, you begin to realize that all kinds of neat things are possible. Take this for example:

<table>
<r><th>Numbers:</th></tr>
<%
for ( int i = 0; i < 10; ++i ) {
    %><tr><td><%= i %></td></tr><%
}
%>
</table>

Remember that everything not within a <% / %> block is converted into out.write() statements. When the page has been preprocessed and it's ready to be compiled, the result will look like this:

    out.write( "<table>\n" );
    out.write( "<r><th>Numbers:</th></tr>\n" );

    for ( int i = 0; i < 10; ++i ) {
        out.write( "<tr><td>" );
        out.print( i );  //  "print" is used for numbers
        out.write( "</td></tr>" );
    }

    out.write( "</table>\n" );

So you can put bare HTML inside a loop, or inside an if, and it will work the way you'd like it to. Take note, however, that there is a "gotcha" here: You need those curly braces around the loop's block. In your JSP file, it looks like there's only one line of code in the loop, but in fact, there will be three lines of code there when the code is compiled. Without braces, only the first line will be inside the loop. This is why it's important to understand what software is really doing, rather than just memorizing the interface.

The feature itself is wonderful: It's really nice to be able to put large chunks of literal HTML inside a conditional or a loop. You can do the same in ASP, for the same reason: Your "embedded code" is really the only part of the file that the server takes literally. When the rubber hits the road and the file is processed, the "literal" HTML will in fact be embedded in your code, not vice versa.

JSP supports another strange and wonderful feature, called tag libraries. These are "custom HTML tags" which invoke Java code when the server sees them. They're never handed along to the web browser that made the request, because the web browser has no clue what they mean. Instead, the server uses them to generate HTML. You could do the same thing by defining a library of functions, but tags are easier to use and they make vastly more sense to a lot of users. The intent of this feature is that a company can have web programmers (so called) writing tag libraries, and web designerss (so called) using them. The latter group can invoke Java code through familiar, friendly syntax without having to learn a real programming language. It's not really all that miraculous. It's just a handy way to do some abstraction and modularization.

Imagine, for example, that you want to use a standard page header on every page on your site. Some of the information in that header is page-specific (the title, for example), and some not. The header's a bit complex: It's got some images and a table or two. You don't want to copy and paste that into every page, especially since it may change next week and you'll have to go back and change all those pages. So you write a custom tag which generates the header. The non-technical people writing actual pages can use that tag like so:

    <our_title back-color="papayawhip">Table of Contents</our_title>

The content of the tag ("Table of Contents") and the attributes ('back-color="papayawhip"') are passed into the code that implements the tag. It does whatever it likes with this information and generates real HTML code, which it passes back to the web server. The web server replaces the tag with that and sends it off to the client browser which requested the page. The custom tags can be nested: The innermost one is executed first, and the content that it generates is passed to the next outer one as part of the outer tag's content.

The process of actually writing these tag libraries looks a bit complicated to me (and I haven't done it yet, either), so I won't try to go into any detail on that.

If ASP supports anything like this, I'm not aware of it. The Everything Engine, by the way, has a feature called htmlcode which is somewhat similar.

Implementations

Apache's JSP implementation is called Jakarta. There's an interface between it and the Apache web server, mod_jserv, but the status of mod_jserv is a bit obscure. It seems to have been replaced with mod_jk, about which I know little. My exposure has been through the Apache Projects's Tomcat web server (which is really a just one part of the Jakarta project, and which also handles Java servlets). Tomcat is itself written in Java and you might say that it supports JSPs more or less "natively", much like IIS supports ASP. I don't think you'd want to use Tomcat for a site with a lot of traffic. The project we're using it for is the management interface of an embedded PC unit. Traffic will be exceedingly low and system resources are abundant.


1 http://www.php3.org

2 The Everything Engine does not work this way: Bits of code are embedded like so:

    <p>[% return 'Example!' %]</p>

Each of those [% / %] blocks is evaluated on its own and the HTML is passed straight through. This means that while in a JSP page you can declare a variable in one block and reference it in another (see the parsed ready-to-compile example above), you can't do that in Everything. The blocks are isolated from each other. This isn't as bad as it sounds, because Perl lets you quote multiline strings: That feature eliminates so much nonsense that it becomes practical to put all a whole page, code and all, inside one [% / %] block.



Thanks to Jetifi for information about Tomcat, Jakarta, mod_jserv, and mod_jk -- and also for some welcome reassurance that the rest of my content was reasonably accurate.




Later thoughts: Java is not ideally suited to generating web pages. In my view, the programmer would be better served by a language more oriented towards text processing, like for example Perl or even JavaScript. A JSP implementation which supported either one or both of those would please me. This brings up other issues, I suppose. To be honest, Java gets on my nerves in general. It reminds me of Pascal: It "smells" like the design was pretty well finalized before anybody had a working implementation to play with. I'm new to it, but so far, I'd say that it sounds better on paper than it turns out to be in practice.

Log in or register to write something here or to contact authors.