Slashdot Mirror

Well, maybe I don't understand what it is that is so special about Dream Weaver's templating engine, but it sure doesn't sound like anything too special. It would be fairly easy to do the same thing with WebMacro (site down at the moment), or it's spinoff Velocity. Although both are intended as "Templating Engines" that run on the server, it's easy enough to set them up to generate static content the way that the article describes. Similarly, more extensive content management systems like Apache Forrest, which is based on Cocoon are available. I don't see what the big deal is.

WebMacro has moved into the beta phase of release 2.0!

WebMacro is the original templating engine that velocity is based on. Unfortunately, due to licensing issues, they were never able to merge and have now diverged enough that they are now quite different despite the base similarities.

Version 2.0b1 of WebMacro has new and exciting features as well as efficiency gains. One of the most interesting new features is actually a result of the improvements in Java technology itself. The older versions had a lot of factories and contexts in order to get around the inefficiencies of object creation and clean-up, but now, much of this has been removed or hidden because of improvments in Java garbage collection has made them supurflous.

As long as we're talking about templating engines, you might also want to have a look at the alternatives as well.

As mentioned below, Velocity is one of the possibilities, but there are others, including Webmacro, FreeMarker, and Tea. Each of these have thier own advantages and disadvantages, but all primarily focus on have a Model-View-Controller architecture, and try and enfoce separation between templates and the data the populates them. This is usually where JSP and ASP sites tend to fall down in practise.

And yes, I do have a favourite ;)

Nicholas.

I disagree with your interpretation of the YMTD article, and certainly with your assessment of Velocity .

However, I think that despite the theatrics, you have some good discussion points, and I (and others in the Velocity community) would be happy to discuss on our user list.

I believe that Velocity and it's kin ( WebMacro , for example) are strong, viable alternatives to JSP, and believe that after more discussion, and you actually trying it, you may see some validity to this assertion.

I invite you to repost your article to the velocity-user list (velocity-user@jakarta.apache.org). The instructions for subscribing start here

geir

It's even easier to build a great OO design (using the Model-View-Controller pattern) if you dump JSP and use a template package like FreeMarker, Velocity or WebMacro. JSP lets you embed Java code in your webpage, so business logic gradually creeps out of your servlets and into your HTML, making maintenance more difficult. Template packages help you keep your business logic and page design separate by keeping the code in the Java servlets and the HTML in the webpage templates.

• For people dealing with very large and varied sets of XML formats ... it is infinitely more maintainable to have the conversions ... written out as a set of XSL sheets instead of ... one rat's nest of perl script after another.

My data is always in the form of some kind of Java object or collection of Java objects. I suppose that if I were a Perl programmer, I'd have some Perl arrays, hashes or object containing my data instead.

An XML document in a file or a memory buffer does me almost no good whatsoever, so the closest I'll ever have to an XML document is the JDOM tree resulting from parsing the source document. This JDOM tree is, of course... you guessed it... a collection of Java objects. Again, if I were a Perl programmer, I could use Perl's powerful text munging to stay closer to the original XML, but I'd still end up parsing stuff out of it.

Seeing as how my data is not in XML documents, but in Java objects, I have a variety of standard, non-confusing, error-free and flexible ways of turning it into HTML, WML, PDF, TeX, MIF or some kind of XML. WebMacro is a personal favorite.

XML is a useful data description and interchange mechanism, but things got way out of hand before people finally figured out what they really wanted to do with it. During this time, I saw several systems that operated on data by passing it around as XML documents. This might make sense in a server-to-server context, but within an application, it represents a fuckload of unecessary parsing and reconstituting of XML documents. If I already have the data in a format that is convenient and accessable to my programming language of choice, why the hell would I turn it into an XML document, unless I was exporting it to some "black box" on the end of a socket connection? Because it's trendy?! No thanks!

XSL and XSLT are predicated on the idea that my data will be in the form of an XML document while I'm working on it. In practice, it turns out that this is extra effort. If I find myself in the position of being given existing XML documents that need only to be converted to another kind of document, I'll revisit XSL, but I tend to work on more dynamic data than that.

Tomcat is a reference implementation that is moving toward being a viable product for small self maintained sites. I use it for testing because I find that its instability and open development strategy are plusses.

There are real commercial Servlet Containers that are much faster and more stable. Resin is blazing fast, includes lost of fun gadgets (but start with plain servlets, please) and is OPEN SOURCE. It's free for small installations, but costs US$500 for commercial licenses. I use it.

What I really like about Resin is that it is rock solid. And nicely supported.

Servlets are at their best with complicated, large, or frequently updated sites. Consider a framework like Turbine or a templating engine like WebMacro or both to build a good quality maintainable site.

JSP is designed to emulate ASP. It's a great transition path. Now some taglibs exist to make it a viable platform for development, too. But a real framework is better, so consider one.

-B. Earl

JSP is not a good scripting engine for Java in my opinion. It forces you to put all your code and your HTML together in one place. A real mess. I have the same problem with ASP and PHP.

Check out WebMacro: webmacro.org

WebMacro is a Java servlet template engine which allows you to separate this stuff. You write pure Java code in the back end, and straight up HTML with some formatting codes in the front.

It makes everything really clean.

Standardized (albeit by Sun), extensible APIs, especially on the server end, and extensible products, is part of what makes Java thrive today. Transaction API, J2EE, JNDI, Java2D/imaging, Java3D, servlets, JDBC, CORBA. Plus a host of pre-packaged libraries for things like sockets and RMI. Products: object databases (Ozone, the Castor O/R mapping framework), transaction managers (Tyrex), web servers (Resin, Jetty, Orion, Enhydra), XML etc.

Above all, Java connect to anything, provides a lot of freebies (garbage collection, a simple object model), is high-level and easy to learn, and lets you be more productive right out of the box as opposed to languages such as C++. No wonder new stuff is sprouting up like mushrooms -- a phenomenon that I suppose Bjarne Stroustrup is mildly annoyed about and doesn't quite understand. Once you've written a C++ app, it's a dead end. It not reusable. Unless you wired it up with magical strings and CORBA and reinventing all sorts of technologies, it just sits there.

This is much the same reason Python is thriving, really. Unfortunately, Java currently does not have anything that comes close to Zope. Turbine and Cocoon sound like two different projects aimed at this area, but they're not even close.

Who cares about Amex or set-top boxes? Unless I can write TiVo-like apps on my desktop computer that controls the box in interesting and hitherto-unrealized ways, it's useless, just another closed implementation. And Amex, well, how do I connect to my card, then?

Now:

• Both Oracle 8i and IBM's DB2 use Java extensively both for their DB administration GUIs as well as for middleware code. If you didn't know, these are the number 1 and number 2 Enterprise database systems in the world

I wish you hadn't mentioned that. Oracle's bloated, clunky Java GUI stuff is their big black sheep. I wish they never screwed this part up -- Oracle's native NT tools used to be at least adequate. Compare Oracle's present, slow, unstable, overdesigned, Microsoft Bob-like Java GUIs with Microsoft SQL Server 7.0's flashy, fast, and hugely functional tools and you just want to crawl into your mama's arms and cry like a baby.

• Java servlets and JSP are used extensively on the web from sites like mail.com to Firstunion.com. Hundreds of sites use Java(TM) to deliver dynamic content these two are simply the most prominent that come to mind.

Servlets is hardly Java's finest moment, same goes for JSP. True, servlets replace CGI in a nice way, and anything is better than ASP and assorted horrors, but that's about it.

Servlets make up a very low-level layer, and servlets themselves are quite isolated entities, compared to the riches of Zope's DTML documents.

Please, developers, do yourselves a favour and read up on how to properly divide content, logic, and presentation. Hint: Putting Java inside HTML gives you no cigar. Look instead at things like Freemarker and Webmacro, or even that bastard son of template processing, XSLT. Even so, these are quite weak tools, and you need to buy a $35,000-per-CPU app server to get any sense of an integrated package.

End of rant.

For some time now, I have been using webmacro as my templating engine and have found it to be extremely powerful, especially in situations such as these. Webmacro's main design approach is based around the "Model/View/Controller" paradigm where the back-end data set is your model, the templates are your view and the webmacro based servlet is the controller that ties everything together. The advantage of a system such as this is that you never need to include any language awareness into the template at all, the only thing that would matter would be the abstract structure of the document in question (which can be broken down into whatever granularity you would prefer to use - pages/sections/paragraphs etc etc).

The controller would then be responsible for making a decision on what page and which language version was required either by virtual directories (/english/category/doc.html) or file extensions (/english/doc.en.html). The category would define the choice of template and the language would modify the query to a relational db. However, the information that is passed to the template is passed packaged by structural role rather than by language thereby enabling the template to render the page completely independantly of language type.

In order to deal with the generation of text buttons (if needed), then I would use java to build a scheme module that is then run through gimp. I've had at various other batch based manipulation packages, but haven't yet anything that gives you the range of freedom and quality that gimp does.

If the data set that is being used to generate this site is static then there is absolutely no reason to generate the site dynamically on the fly and it is better to cache the whole site onto a static file system (unless it is prohibitively large) and then just rebuild it whenever the data set is updated.

The other final advantage that using a system such as webmacro gives you is that it is possible to very easily test out your navigational systems without having a large data set of information already stored in the db. If you replace the model with a virtual model that supplies random text within the contexts requested then it is very easy to test out situations like "Does this tree navigation work as well with deeper trees and more than 5 languages?" without changing either your servlet or your template design.

For some time now, I have been using webmacro as my templating engine and have found it to be extremely powerful, especially in situations such as these. Webmacro's main design approach is based around the "Model/View/Controller" paradigm where the back-end data set is your model, the templates are your view and the webmacro based servlet is the controller that ties everything together. The advantage of a system such as this is that you never need to include any language awareness into the template at all, the only thing that would matter would be the abstract structure of the document in question (which can be broken down into whatever granularity you would prefer to use - pages/sections/paragraphs etc etc).

The controller would then be responsible for making a decision on what page and which language version was required either by virtual directories (/english/category/doc.html) or file extensions (/english/doc.en.html). The category would define the choice of template and the language would modify the query to a relational db. However, the information that is passed to the template is passed packaged by structural role rather than by language thereby enabling the template to render the page completely independantly of language type.

In order to deal with the generation of text buttons (if needed), then I would use java to build a scheme module that is then run through gimp. I've had at various other batch based manipulation packages, but haven't yet anything that gives you the range of freedom and quality that gimp does.

If the data set that is being used to generate this site is static then there is absolutely no reason to generate the site dynamically on the fly and it is better to cache the whole site onto a static file system (unless it is prohibitively large) and then just rebuild it whenever the data set is updated.

The other final advantage that using a system such as webmacro gives you is that it is possible to very easily test out your navigational systems without having a large data set of information already stored in the db. If you replace the model with a virtual model that supplies random text within the contexts requested then it is very easy to test out situations like "Does this tree navigation work as well with deeper trees and more than 5 languages?" without changing either your servlet or your template design.

Really, I do this stuff for a living (primarily in server-side Java and these suggestions may show that), and there is no easy way I know to get great maintainability and high performance. Here are a few things to consider, though (there may be some information that was in previous posts):

• The first thing to consider is what the scale of your system's complexity is. For the simplest sites, try to stick with static HTML as much as possible. Use a server-side process to update those files once or twice a day. For moderately complex systems or systems that just need to be updated more quickly use something like PHP or Cold Fusion with a simple database. For highly-dynamic sites with complex business rules, you'll need a well designed, application server-based system. The rest of the comments are on how to build these types of systems.
• To make your system the most adaptable it can be, concentrate on the "problem domain" or "business rules". Design an object-oriented problem domain. Keep that problem domain code as separate as possible from the "presentation" and the "data managment" code. Generally, we have separate Java packages for problem domain, presentation logic, and data managment.
• Find a way to cache instantiated problem domain objects in memory. Object pools, Enterprise Java Beans, and object caches are things to look into.
• Cache semi-static results. Even in a highly-dynamic system, it is likely that less than 25% of the site is really that dynamic. In an e-commerce site, the inventory levels might change, but the product information (descriptions, images, etc.) will not. Design your presentation logic such that you can cache as much of these results as possible in memory.
• As you can see from the previous two, go heavy on the RAM on your servers.
• To handle heavier loads, never have the same web server handling both application requests and static requests. Off-load static HTML and images to another server (or group of servers).
• Use an application server that supports load balancing. EJB is a good (not great, but it's pretty widely available) method for distributing the problem domain load.
• To aid in the maintainability of the presentation, use a template engine or use JSP, but treat it as a template engine. Examples of template engines include WebMacro and FreeMarker. Don't put code in the HTML or HTML in the code if you can at all help it.

Well, I'll stop there. There's plenty more to cover, but there are also plenty of books out there. Basically, in my experience, the first rule of maintainability is keeping the problem domain separate, and the first rule in performance is caching.

The best two systems I have seen for separating content from presentation are both based on java.
Enhydra and Webmacro. You may want to check them out and both are open source.

This is great news. I had been holding the WebMacro servlet framework to 1.1.8 because there wasn't good support for Java2 on free OS's.

Now I can move it forward to Java2!

• The LGPL (which this is similar to) is 11 pages, and none of my users are willing to read it. Since half of them run my Java servlet framework (WebMacro) on NT it isn't true that they have already heard of LGPL.
  
• It allows a distributor like Red Hat to continue shipping CD's even if they contain a program on them with a violated license. Under LGPL they would have to recall the entire run.
  
• It makes a stronger assertion about crediting the author--for web software, I would like it if my name appeared somewhere where the actual end users could look it up. Under LGPL/GPL your name only appears in the copyright statement, not in the list of authors.

The key insight into XML is that it should be used only where other solutions fall apart. XML is one of those technologies that is so general, so abstract, and so powerful that you can construct a solution for ANY problem.

The downside is that the solution will involve extra processing steps, extra stuff to be implemented, and impose on you a development model that might not always be convenient (not everything wants to be a document, or a conversion or transcoding between document formats).

However, there are many cases where XML is the only viable solution, and in those cases you're just glat you can solve the problem at all! A typical example is when you have documents coming from multiple sources, and you publish them to multiple targets. It's easy to see what the XML solution would look like--but the problem doesn't even fit into the other ways of doing things.

With WebMacro a common implementation strategy is to drop key XML objects into a template that is otherwise created through ordinary WebMacro HTML template gunk.

The advantage of this approach is that you can create the bread-and-butter stuff like shopping carts, authentication, login/logout, using ordinary Java servlet code and templates. (These things are nasty when you try and force them into a document model).

Then in the middle of your page somewhere you have your XML document, rendered using XSLT or something. You have other targets, besides your servlet, where you publish that same XML document, so the whole thing winds up being a rather pleasant mixture of two different programming paradigms.

Again, the key insight in this strategy is that you use XML for the parts of your problem where it is the only viable solution--and you do everything else the normal way (without the extra costs imposed by XML, since you don't need the extra power).

I worked in an SGML shop for a couple of years, and became smitten with SGML/XML. I set out to do absolutely everything I could in SGML/XML for awhile, before realizing that a traditional template tool (like WebMacro) was far more useful for typical bread and butter servlet programming.

I still use XML a lot, but now I use it intelligently, where it's needed!

The key insight into XML is that it should be used only where other solutions fall apart. XML is one of those technologies that is so general, so abstract, and so powerful that you can construct a solution for ANY problem.

The downside is that the solution will involve extra processing steps, extra stuff to be implemented, and impose on you a development model that might not always be convenient (not everything wants to be a document, or a conversion or transcoding between document formats).

However, there are many cases where XML is the only viable solution, and in those cases you're just glat you can solve the problem at all! A typical example is when you have documents coming from multiple sources, and you publish them to multiple targets. It's easy to see what the XML solution would look like--but the problem doesn't even fit into the other ways of doing things.

With WebMacro a common implementation strategy is to drop key XML objects into a template that is otherwise created through ordinary WebMacro HTML template gunk.

The advantage of this approach is that you can create the bread-and-butter stuff like shopping carts, authentication, login/logout, using ordinary Java servlet code and templates. (These things are nasty when you try and force them into a document model).

Then in the middle of your page somewhere you have your XML document, rendered using XSLT or something. You have other targets, besides your servlet, where you publish that same XML document, so the whole thing winds up being a rather pleasant mixture of two different programming paradigms.

Again, the key insight in this strategy is that you use XML for the parts of your problem where it is the only viable solution--and you do everything else the normal way (without the extra costs imposed by XML, since you don't need the extra power).

I worked in an SGML shop for a couple of years, and became smitten with SGML/XML. I set out to do absolutely everything I could in SGML/XML for awhile, before realizing that a traditional template tool (like WebMacro) was far more useful for typical bread and butter servlet programming.

I still use XML a lot, but now I use it intelligently, where it's needed!

First of all, I recommend the O'Reilly Servlet book.

Second, pick your servlet engine carefully. I saw the reference to some hello world tests in a previous post. The servlet tests look like they were run on Apache's servlet engine. Too bad its dog slow (last I read about it that is ~6 months ago--I'm sure that they will catch up). We used Servlet Exec, and it works well. Also, be careful to not to let yourself be misled by micro benchmarks.

Third, consider your needs. In our servlets we were able to take advantage of object caching, sophisticated object to relational mapping tools and CORBA connectivity to back end services. There's a very nice java servlet framework called Webmacro, which is free (as in software not beer). I also see potential in JSP's, although I have no direct experience with them.

I also saw some comments about Java being slow. Yes, that's true. However I would venture to guess that its fast enough for all but the most demanding applications. Comments from another post said that you'll require serious hardware to do servlets. No doubt. However, computers are getting faster and so are Java VM's. I'm sure that Java will be fast enough for those demanding applications in the next couple of years, and my opinion is that if you want to be ready to slide down that slippery slope (like Chevy Chase in Christmas vacation) when its slick enough, then there's no better time to start greasing up with the right lubricant and getting the experience than now.

In short, we've had good luck with servlets. Developement has been quick (most of the development speed gained in Java is cut out from debugging when compared to c/c++ I can't compare it to perl though). The web sites have performed well. Personally, I believe that developer time is more valuable than CPU time, so I would recommend (IMHO) spending the extra dollars on hardware, and saving on the developement and maintenence.

Good Luck

My question is regarding your warnings about JSP. I not sure I understand the design differences between JSP's and the WebMacro approach. Is it that the latter is simpler to use than java?

I haven't used JSP's yet, so please forgive me if I'm missing something obvious.

BTW, another article along the same lines is Design Java servlets with the Delegation Event Model.

WebMacro will gradually kill JSP :-) In fact, it was recently selected in a Java Report survey as one of the best three servlet products of 1999.

JSP is not a good use of the Java langauge. It's non-standard, and requires extra junk in your webserver (whereas WM works in any pure Java environment, without requiring add ons). On top of that, it doesn't take advantage of Java's features. It looks and smells like ASP, and as a result, obscures your ability to write good clean Java code.

If that's the kind of programming you want to do, you should look into EMBPERL. It does a much better job of mixing script codes into HTML.

My view is that you should NEVER mix program logic and HTML together. WebMacro implements a template langauge, the idea being that all your rendering logic and HTML goes in the template--leaving your servlet as pure and simple Java code.

JSP's model is the opposite, though they claim you can do MVC programming with it. (A claim they started pushing *after* WM was announced, by the way :-)

With JSP you can do MVC programming, keeping your busines logic separate from your display logic, but you have to enforce it yourself. Every time you do anything everywhere you have to follow self-imposed rules. Late some tired night you'll get fed up and sick some Java into your HTML--like a cancer it'll grow, until the point in separating them is lost.

WebMacro, or any other template system, supports the model/view/controller way of thinking architecturally. It's analogous to doing OO programming in an OO language, as opposed to in C. Separating display from logic in JSP is like doing OO programming in C--it's possible, but the language doesn't really support it.

It is worth repeating that I created WebMacro in response to JSP. I had come from a perl/C++ background, and had made extensive use of good template systems in both langauges. Coming to Java, I naturally expected to have a good template system, so I looked at JSP. When JSP turned out not to be a template oriented system, I naturally wrote one and GPL'd it :-)

Of course I'm biased. However, I will say that the bias caused me to write WM, and not the other way around :-)

This is just nasty propaganda, with hardly any truth to it.

(1) What's this BS about corporations using Java and private individuals using C? Do you have any evidence of it? It seems like a wildly ridiculous claim at face value. My best guess is you are saying all Linux programs are written in C, whereas the websites corporations build are backed up by Java. That's confused and silly, since those are two different kinds of programs.

(2) What happened to perl? Almost everything done on Freshmeat is NOT python. It's mostly perl and C. I think your biases are showing, as is your lack of factual data.

(3) I am a private individual, self-employed in fact, and I use Java and Perl about equally. I even wrote and contributed a template engine for Java servlets, which you can find on freshmeat, called webmacro. It's free under the GPL, go try it out.

Also I don't have any clue why you mentioned CORBA. CORBA certainly has had problems gaining widespread acceptance--but I don't know why you think there is any connection to Java. CORBA is just as well connected to python and C; the Java bindings came fairly late in the process (after python, for example). So while your criticism of CORBA may have a point, it isn't relevant to a discussion on Java.

I can't believe you propose to use Python on the server, and in the next sentence you are complaining that Java is slow.

There are lots of great things about Python, it's an amazing lanaguage, and a substantial improvement over Perl. However, speed is not one of it's attributes. Python is dog slow, and Java runs circles around it.

Putting a bytecode interpreter on a PCI card is a bad idea as well. The problem is that you wouldn't have a processor on the card nearly as fast as the one in your PC.

Java is only slow on the server if you compare it with C. Versus any scripting language, it's lighting fast.

With WebMacro servlets I find that I get performance equivalent to what I get out of PERL running as an Apache module.. and WM is doing a lot of work for me.

BTW, WebMacro is actually an HTML template langauge. You write a template that contains some dynamic content, but without knowledge of where that content comes from. These templates look like ordinary HTML documents, with a few extra things dropped in.

In the back end you work with ordinary Java objets, anything vaguely bean-like. You just drop these into a hashtable and WebMacro's introspector figures out how to fit what you've supplied in the hashtable together with what you've asked for in the template.

The goal, of course, is to keep your Java servlet code clean and clear, with no HTML--and similarly to keep your HTML clean and clear, with no program code messing it up.

There are other template solutions for Java servlets besides WebMacro. FreeMarker is one. Another way to go is to use XML with XSLT. I would advise against using JSP. JSP is great if you are familiar with ASP and you're looking for something familiar in the Java world--but I don't think it's a good use of the Java langauge. On the other hand, attracting all these ASP peope to Java is good *for* the Java langauge :-)

I developed and wrote WebMacro which is a free (GPL) Java servlet framework.

I use Java for about half my web projects. The other half of the time I use perl. In my opinion, here are the strengths of Java for server side development:

1-- It allows clean and clear design. Since you can declare compiler-enforced interfaces, you can easily separate out functionality in well defined chunks. This allows you to plan for the long term, hand different parts of the project to different people, and so on. This tends to be what makes me choose Java over Perl: If I want to enforce a long term design (such as re-usable constraints on busisness logic), or break the project up into several different segments, then I choose Java over Perl.

2-- It's fast and scalable. Java is often criticized as being slow, but on the server, it's not. It's fairly fast compared to things like perl (which are usually fast enough to begin with), and add to that the threaded nature of servlets, plus the built in scalability, and you have a big performance gain over other scripted solutions. In particular the ability to automatically distribute a single servlet across multiple webservers, without modifying the servlet itself at all, is a big win. You can be sure that whatever you do will scale.

3-- You do need to make an effort to keep your HTML and your SQL and your Java program code separate form one another. The whole reason for using Java was to get clean, well designed code, and you don't have that when you have HTML obscuring your servlet. This is what prompted me to write WebMacro, which is an HTML template system, but you could also do this with FreeMarker, or XSLT, or if you are very careful, with JSP.

4-- Write once, run anywhere is fairly real on the servlet. I routinely develop under FreeBSD, deploy on FreeBSD, Solaris, and Linux, and I have about half the users of WebMacro running it under NT, even though I myself hardly ever use NT. And it all works.

5-- On the downside, the free Java solutions don't appear to work very well for servlets. I have had lots of trouble with kaffe, and the free JVM's are not as fast as the non-open ones. This is too bad, and it's something I expect will change over the next while. I always try kaffe every time it comes out, but it hasn't yet been stable enough for me.

6-- You do need an experienced designer around if you are going to use Java. Unlike perl, where your goal is to hack out something working ASAP, in Java the point of the language is to allow you to do clean design. Well you won't get clean design without an experienced designer. Without a good designer you are probably better off with "write-once" perl-code that you throw out and rewrite whenever you need to fix it. While Java allows you to do really good design, I have seen some really nasty Java code. If you aren't going to use it right.. don't use it.

I developed and wrote WebMacro which is a free (GPL) Java servlet framework.

I use Java for about half my web projects. The other half of the time I use perl. In my opinion, here are the strengths of Java for server side development:

1-- It allows clean and clear design. Since you can declare compiler-enforced interfaces, you can easily separate out functionality in well defined chunks. This allows you to plan for the long term, hand different parts of the project to different people, and so on. This tends to be what makes me choose Java over Perl: If I want to enforce a long term design (such as re-usable constraints on busisness logic), or break the project up into several different segments, then I choose Java over Perl.

2-- It's fast and scalable. Java is often criticized as being slow, but on the server, it's not. It's fairly fast compared to things like perl (which are usually fast enough to begin with), and add to that the threaded nature of servlets, plus the built in scalability, and you have a big performance gain over other scripted solutions. In particular the ability to automatically distribute a single servlet across multiple webservers, without modifying the servlet itself at all, is a big win. You can be sure that whatever you do will scale.

3-- You do need to make an effort to keep your HTML and your SQL and your Java program code separate form one another. The whole reason for using Java was to get clean, well designed code, and you don't have that when you have HTML obscuring your servlet. This is what prompted me to write WebMacro, which is an HTML template system, but you could also do this with FreeMarker, or XSLT, or if you are very careful, with JSP.

4-- Write once, run anywhere is fairly real on the servlet. I routinely develop under FreeBSD, deploy on FreeBSD, Solaris, and Linux, and I have about half the users of WebMacro running it under NT, even though I myself hardly ever use NT. And it all works.

5-- On the downside, the free Java solutions don't appear to work very well for servlets. I have had lots of trouble with kaffe, and the free JVM's are not as fast as the non-open ones. This is too bad, and it's something I expect will change over the next while. I always try kaffe every time it comes out, but it hasn't yet been stable enough for me.

6-- You do need an experienced designer around if you are going to use Java. Unlike perl, where your goal is to hack out something working ASAP, in Java the point of the language is to allow you to do clean design. Well you won't get clean design without an experienced designer. Without a good designer you are probably better off with "write-once" perl-code that you throw out and rewrite whenever you need to fix it. While Java allows you to do really good design, I have seen some really nasty Java code. If you aren't going to use it right.. don't use it.

For server side stuff, and for embedded stuff, Java is the way of the future. I'm glad to see movement in this direction--personal Java for Be has some real potential. Java is the only credible threat to WinCE in the long run. (Much as I like the palm pilot, it's internal memory model and APIs just don't give developers enough to work with.)

However, I have to say that I don't see much good in the future for Java as a GUI platform. Be is definately a GUI platform, so it seems to me the first step is to get that stuff working, at the technolgoy level. Maybe the Be developers can return the favour and help make Java an effective GUI platform.

Realistically, the competition is shockwave--it's fast, slick, and definately well on its way to being a class one killer app.

Java just isn't competing here--it's still slow, clunky, and cumbersome. It's pretty obvious that Sun spent 10 years perfecting Java for embedded and server applications, making a damn fine product. But then they hacked a bunch of GUI stuff onto that in a few short months and called it a "web applicaton". Applets are an outright disaster, and GUI applications don't fare much better.

Which is a shame, since it's such a good idea. Shockwave is going to kill Java unless something is done to speed up the raw GUI performance.

Don't take me as a Java hater, I'm not--I love Java on the server, and even have a big free software project devoted to making life easier there (webmacro). I just don't like the Java GUI.

Ya, I did one servlet before I said this is stupid. So my business partner and I built a template framework, which completely (well 99%) separates the HTML from the business logic. The end result is pretty slick, and is a simplified version of webmacro.

Many programmers can build an application. Few can build good libraries

Ya, that why my partner and I haven't hired anyone else yet... :)

Web Macro has been mentioned above. I'd like to add that I'm using it, and it's pretty cool.

* It's surprisingly fast (providing you avoid the slow include file directive, which they say will be fast in the next version as well)

* It's easy to make templates

* It's easy to write the back end code too because Web Macro uses introspection to analyze your object--no need for an adapter class.

* Full separation of content and presentation. JSP claims this, but it's actually real in Web Macro

It's open source. The only downside is that 1.0 has not yet been released yet I don't know when that's coming out, I think a few months or something. However the current beta seems very stable to me.

Also you have to be careful with your classpath when installing it. However once I got it installed correctly, it was a blast.

Web Macro

I use webMacro to build my servlets. I have 10 production servlets running with it, and it's great. webMacro separates your HTML from your code cleanly, and unlike JSP it's open source.

OK, here's the scoop. I *DO* servlet programming for a living. We've pulled together webmacro, IBM WebSphere AppServer and MySQL on Linux. But if I had a choice, I wouldn't be using IBM WebSphere. We got lucky, and didn't have to pay for it. It's mostly fast, and does everything we need it to - for now. But it's got it's flaws, and it's a resource pig - 30Meg of Memory to run two servlets? And It's the only app I've seen to Max out CPU Utilization on Linux. Hell, it's the only thing I've seen *KILL* apache deader than a doornail. We're still looking at the OpenSource Servers because they look smaller, faster, and just as feature rich. Please Tell me which one you choose, and why. I want to take it to my boss as an alternative.

webmacro

webmacro.org

It's a template engine that makes servlet programming a breeze. Keeping HTML out of your code is important.

Java servlets are persistent, which lets you take a different approach to servlet design, see:

this servlet design article.

GPL I think.

It uses introspection to allow dropping objects into a template. Much nicer than JSP.

It's GPL.