Slashdot Mirror

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.

I was impressed.

Another problem is that GSP was written to the Servlet 2.0 spec, and fails to run under 2.1/2.2 compliant servlet runners. If you have to run JSPs within a servlet 2.0 environment (like apache jserv), look at gnujsp, which is largely JSP 1.0 compatible.

I don't know the particulars of your application, but by decoupling the content from the presentation, you gain an enormous amount of flexibility and power.

By creating content as XML, you can now create XSLT scripts to transform that pure content into an arbitrary presentation form. So you can write an XSLT script that transforms your XML content into XHTML or into WAP. This is powerful because now you can serve multiple different requestors with the same content.

There is a project called Cocoon (from the Apache Software Foundation) that does this exact thing. Cocoon itself is a servlet, so it gives you a choice of what servlet engine to run it on. It provides good caching, XSLT transformations, and even a "sitemap", which is a central location for binding look&feels to content.

There is an open source servlet engine that has built in XSLT processing, XPath processing, and XML parsing. It is extremely fast and has a lot of features. It is Resin. I recommend this one. Because this is a full blown servlet engine, you have JSP processing, session support, and it is even a small web server.

Man, people get DAMN religious about this one. I totally support back-end components, because they increase the readability/maintainability of code and enable code re-use. However, I CONSTANTLY hear about people taking this to unnecessary extremes.

For instance, I really enjoy working with JSPs. The "purists" complain that they encourage you to put code in HTML, but, damn it, there are times when you need code in HTML, such as loops, if/else logic, and tiny utility functions. Forcing all of these into the back-end components ends up putting too much presentation into the logic, so the components lose their generality.

If you constrain your Java-writing to the syntax you learned in the first week of "Teach Yourself Java in 21 Days" (i.e., don't do any serious coding, and don't import packages other than your custom components and java.util in most cases), you'll be in good shape. Why use a separate macro system (as I used to do before I switched to JSPs), which will simply force you to learn another syntax? Just don't go making frickin' SQL queries from your JSPs, either!

By the way, I do recommend Resin from caucho.com if you're interested in JSPs. It handles some cool things, like database connection pooling (very important!) for you and, coolest of all, it supports JavaScript as a for JSP development. Just as serious Java coders shouldn't have to go learn some other macro syntax to code pages, web designers should be able to use a language familiar to them, which, in almost all cases, is JavaScript.

--JRZ

Poor programming seems to make more of a difference in Java performance. For example, the web-server/servlet-engine performance varies by a factor of 3 or 4 depending on the implementation (here's a simple benchmark).

I've also seen differences of 2x or 3x for JDBC drivers. Unfortunately, I don't have benchmark numbers available.
Scott Ferguson

Care to back up that claim with some data? Servlets can be just as fast as mod_perl or mod_php. See this benchmark.

Besides, Java isn't really interpreted any more. Thinks of the Java bytecodes as a (mostly) platform-independent distribution language.
Scott Ferguson