What Perl Could Learn from Java WARs

A business partner convinced me to work on a short-term Java web programming contract with him, and the details were right. (My most recent Java programming experience was an experimental project for a very large middleware company a couple of years ago that gave them a lot of information at the cost of a lot of frustration.)

The experience has been enlightening.

One bright spot is Java's notion of web deployment. It has its obvious flaws, but it has obvious benefits. You gather all of the artifacts necessary for your project: XML files, JAR files (bundles of Java libraries), web templates, the classes you've written, and other resources, all in the appropriate subdirectories governed partly by convention and partly by a manifest file. Your deployment process bundles everything up in to a WAR file (a web archive). Then you dump this WAR file into an application server.

Compare that to another project I delivered recently where I sent a CPAN-style distribution tarball to a (much more technically savvy) client, who set about installing dependencies from the CPAN (where Module::Install couldn't get the job done) and from yum, where you don't want CPAN installing, for example, PostgreSQL for you.

Granted, I could have used a tool such as Shipwright to bundle my code, but I didn't. For better or worse, CPAN-style distribution is awfully common.

Imagine instead if I could have bundled everything up into a single WAR-style file which a hypothetical Perl web application server could deploy.

Java achieves this in at least two ways. First, Java wants to own the world—Java does have bindings to native code, but the Java desire to have pure-Java everywhere tends to encourage people to write pure-Java code where Perl hackers might write XS. (XS means you have to compile native code on the target deployment platform.) Someday perhaps Perl 5 can reduce its reliance on XS.

Second, Java application servers also have the advantage of a stronger memory separation between different applications running on a single JVM. Some of this is due to the static nature of the Java language. When you can resolve all references within an application at load time, you don't have to look things up by strings in a global directory. (Of course, you do have to be clever in your VM design to allow runtime reflection, so the implementation of the VM is also important.)

Plack offers a way around this. Imagine a Perl app server based on Plack to which you can deploy multiple applications. The app server could start multiple independent backends—even so far as having multiple installations or at least library directories for each application, as necessary—to use Unix process separation to achieve this memory separation.

Such an approach would still likely use less memory than Java.

Make the Plack app server a reverse proxy capable of serving static files and SSL and redirecting invalid requests and you might have something really exciting. (Make it cloud aware and give me a 10% equity stake.)

These are idle musings, and the Java ghetto doesn't tempt me to ditch the world of Perl for a work life full of beans and mappers and inversion of control governed by there's-no-angle-bracket-shortage-in-this-sea-of-XML—but even in that mess, there are still some good ideas worth borrowing, buffing, and bettering.