The Challenge for Server-Side Java

I'll start with being up front about my Java background. In all honesty if given the choice between Java, .NET and PHP, Java would be my weakest subject. I've written a total of two relatively small Java projects at work and have read two Java related books (one detailing the syntax of the language and the other demonstrating how to use JSP). As such I'm not an expert with this technology, yet all the same I feel as if I've gleaned some observations throughout my limited experience that are worth sharing.

It's a rare thing to find Java being offered from your average web hosting company. Most of them advertise ASP.NET or PHP/PERL as part of their plans...but make no move to go beyond these options. Some of the managed, dedicated hosts (such as Rackspace) offer Java but only by way of do-whatever-you-want-with-your-root-account. And even if a viable Java host is located, the price for such a service tends to be comparatively high.

This is a problem. If server-side Java is to have a future, it must continually be opening itself to new audiences. With less options in small to mid-sized hosting environments, Java is sending an erroneous signal that it isn't as flexible or powerful as competing technologies. Is this because servlet administration is more expensive? To cut down the need for additional hardware, perhaps the JVM can be shared among several applications on one box (similar to the way that ASP.NET shares one worker process among many AppDomains)? Myservlethosting.com describes why a shared JVM might not be a good idea for production applications, even if it might save money on hardware:

A shared JVM is when you share your Java Virtual Machine with other clients on the server. You will use the same memory space as they do. This can mean it being less secure and less robust. Typically there is no security issues, but we felt that we should just mention it. Since you are sharing the JVM with other clients you will not have full control over starting and restarting the servlet engine. Typically a shared JVM is ok if your application is not in production or you are just developing it.

A private JVM is when you have your own servlet engine installed into your home directory and its dedicated to you and only you. This is great for serious developers that need the FULL control over the configuration files, start and restarting the engine, and much more...

I recognize that Java has other barriers to entry. But with tools like Eclipse and Netbeans and a thriving community in the JCP, many past complexities are starting to fade. Hopefully hosting availability for server-side Java will grow to the point where it is affordable, stable and inviting enough to catch the eye of any hesitant hobbyists or small businesses.