We’ve all thought about it. If you search hard enough you can even find a few simple examples of how you might accomplish this. I know Java has some really great frameworks like Grails and Tapestry 5, but even these can be a bit much for some projects and new comers to Java. Fair or unfair, the biggest problem with Java web development outside of the enterprise is how it stacks up against its counterparts: Ruby on Rails, PHP, Python/Django and ASP.net. The problem is almost entirely relative and you’re only likely to notice it if you’ve developed in one of these other environments.
Enterprise Java web development is, what it is. I’m fine using framework X and the 50 supporting libraries it uses when I’m at the office and you need all of the structure that the framework provides. But not all projects need all of the overhead.
Let’s say you want to host your own blog and maybe you need to make some customizations. You need to download it, make your mods and then find some place to host your newly customized blog.
|WordPress 2.8.2||Roller 4.0.1|
|Download Size: ||2.2MB||27MB |
|Hosting Cost:||$3.95/month||$6.00/month (shared)*|
|Technologies:||PHP, MySQL||Java, MySQL, Struts, Freemarker, Acegi, |
Tiles and others
(there are 54 jars in the lib folder)
|Installation time: ||5 minutes||5 minutes (if you really know what |
you’re doing – not my words,
see page 4 of Roller install guide)
All I’ll say about this comparison is that everything is more on the Java side. After over 10 years of Java we have few applications, that aren’t developer tools, that have the ubiquity of a WordPress. We can speculate on why this is so, but I think the answer to the question lies within the 27MBs of JSPs and jar files that make up Roller. We need a simpler option.
Google App Engine
The obvious response to any complaints about hosting Java web applications is: Google App Engine.
The GAE is not perfect but I concede that Google essentially solved Java’s hosting problem. If you’re an experienced Java web developer, there are few better options. However, since the debut of Java support in the GAE, all Java hosting has not moved to Google. It’s simply not the right solution for everyone. Now there’s a place you can host and grow your Java application, now also we need a simpler alternative to the big frameworks. A pure scripting option that gives us the speed and ease of something like PHP.
Groovy without Grails
With Groovy, all of the pieces are available to make a JVM based language available in the LAMP stack. Because Groovy seamlessly integrates with Java , the vast world of java libraries is available when using Groovy.
Here’s what a Java solution for the LAMP stack could look like: SCGI, Groovy and a simple partial re-implementation of the Servlet API. Why re-implement the Servlet API ? Two reasons: familiarity and simplicity. Java developers know it and other libraries (like commons file upload ) are built on it. Only a partial implementation would be needed because certain parts of the Servlet API conflict with the goal of a simple scripting engine. Certain features like, listeners and filters would be 2 that might not be re-implemented. The result would be a “Context” object with very different capabilities than current implementations. Basically, everything about it would be simpler. An application would only consist of groovy scripts. There would be no need for the WEB-INF/classes and WEB-INF/lib folders. Jar files would be loaded by the server and the loaded jars would be available to all of the applications. An application could be represented simply by a folder, no web.xml required. There could be a web.groovy (or something like it) to define the application and session start and end events. Application, Session, Request attributes values would all be automatically serializable so that objects could be persisted to a file, database or caching system. The engine needs to be able to process a request and to be able to completely forget about the request it just processed. If the engine goes down, it should be able to resume processing requests for the previous engine with application and session state still intact. Since Groovy is a scripting language and the GroovyScriptEngine already detects file changes and reload them automatically, you could finally say good-bye to app server restarts while developing.
If you take a look at the source code of the GroovyServlet and SimpleTemplateServlet it’s clear that most of the significant work is already done. These classes allow you to use Groovy without Grails in any web application now. There’s never been a requirement that Groovy could only be used with Grails. With just a few modifications, they could be the core of a SCGI based Groovy script engine.
SCGI has already been proven with and Python and Ruby. With it, the Groovy script engine could sit behind Apache, Lighttpd or even IIS.
Sure there are some security issues to resolve, but nothing the SecurityManager and custom class loaders can’t handle.
Is there room in the java web development space for a pure scripting option. If there was a tool, that allowed you to change the P in LAMP to G for Groovy(and that worked just like other scripting environments), would you use it? If not, why not?