Java suffers from a shortage of hosting

We're hearing from all sides about what's coming in JDK 6 and JDK 7, changes that should make Java development easier, more efficient and better. Java's problem lies elsewhere. For at least some developers the trouble starts when they try to host their Java applications. One myth about Java is that it isn't as efficient as PHP. One reason this nonsense spreads is that you can't easily host a Java web application almost anywhere, the way you can with PHP.

The Czech Republic alone has plenty of free hosts for PHP applications and even more paid ones. It's much the same around the world. You could count the free Java hosts worldwide on one hand. There's more choice in paid hosting, but that obviously won't be enough to popularize Java on the web.

What good is Java's remarkable range of middleware when the most basic thing, somewhere to host an application, preferably for free, is missing? Developers would obviously rather deploy their applications almost anywhere than puzzle over where it is even possible and how much it will cost. You can cobble together an application at home in a few days in either PHP or Java. With Java you can stick it in a drawer unless you pay for hosting or set up your own server.

Offering Java application hosting is easier said than done. In my view, Java as a web platform is very difficult to host in its current model. The biggest problem is isolating web applications from one another inside a JVM. SecurityManager makes it easy to stop deliberately disruptive code such as System.exit(0), but several serious problems remain.

Shared memory space
One web application with a big memory footprint or a memory leak will bring down all the others inside the VM. The VM's memory space has a hard upper bound set when it starts, and it cannot exceed that bound at runtime.
High memory usage
The memory model and the way the garbage collector, which cleans up unused objects, manages it mean that a Java server uses much more memory than a conventional HTTP server. Every HTTP request creates many new objects that become useless when it finishes and wait for the GC to remove them. That's fine in itself, but the GC needs careful tuning so it doesn't run at the edge of a full heap and get called repeatedly, which would slow the server down considerably.

Since version 1.4 it has been possible to influence GC behavior significantly. Memory usage is manageable with a single application under our control. On a public server, many applications run concurrently inside one VM and can interfere with one another in unpleasant ways.

Susceptibility to DoS
Relatively innocuous code can easily cause a denial of service (DoS). Here are two examples. An infinite loop can keep the processor fully occupied until the HTTP request times out.
A second example is making a new HTTP request back to the same server from inside a thread that is already handling an HTTP request. This exhausts the internal threads available to handle requests. The server can still accept HTTP requests but cannot service them internally, resulting in a deadlock. Creating new threads is limited by operating-system resources. On Linux, for example, Java threads map one-to-one to operating-system threads.


Note that some application servers let you configure dedicated thread pools (what's the Czech term for that?) for each application.

The cost of hot deployment
If a JSP changes, the application server can easily compile and use the new JSP. Classes aren't that simple. Java uses a class loader to load classes, and the loader cannot simply swap an old class for a new one. Fortunately, each web application has its own class loader inside the server. When the server detects a new version of a class by watching the file system, it discards the application's entire class loader and reloads the application, or more precisely its classes, using a new loader. That's called hot deployment.


Reloading the whole application each time a class changes is costly in production. The hosting infrastructure therefore has to allow for two servers, production and test. You tune the application on the test server with hot deployment enabled and then promote it to production. That takes a lot more development work than copying a new PHP file to a server.


Note that hot deployment can cause an unpleasant memory leak in Tomcat, for instance, because the GC cannot release the special area of the heap used for class definitions.

Like any problems, these can be addressed or their impact reduced. The question is why Sun tolerates the situation. Java's adoption would no doubt multiply if these problems were solved. There is even JSR 121 (Isolation API, Resource Management API, see A Resource Management Interface for the Java Platform (PDF)), which was used successfully in a prototype of the MVM (Multitasking Virtual Machine) and could go a long way toward reducing these problems.

More surprising still, Sun applied the MVM concept, or aspects of it, to mobile devices, where it had to reckon with limited resources. To top it off, Sun uses PHP for its own site. Whatever the reason, it makes you think they aren't eating the food they make themselves.

It might sound odd, but this is the best opportunity to do something about it. With Java now open source, it is much easier to push for the JSR 121 approach. A portable MVM implementation and an application server using the Isolation API and resource management could be a turning point. In that light it is interesting that BEA WebLogic and IBM WebSphere had their own JVM implementations and never reached for anything like this.

If I had to choose between widely available Java web hosting thanks to an MVM fork of the JVM and the conceptual purity of the JVM, I'd choose the potentially riskier fork…