David has posted 1 posts at DZone. View Full User Profile

Groovy in the LAMP Stack

07.31.2009
| 5790 views |
  • submit to reddit

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.2MB27MB
Hosting Cost: $3.95/month$6.00/month (shared)*
Technologies: PHP, MySQLJava, MySQL, Struts, Freemarker, Acegi,
Tiles and others 
(there are 54 jars in the lib folder)
Installation time:
 5 minutes5 minutes (if you really know what
you’re doing – not my words,
see page 4 of Roller install guide)
* http://www.visionwebhosting.net (no affiliation, just the best deal I could find)  

 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?  

Published at DZone with permission of its author, David Lee.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Erik Post replied on Fri, 2009/07/31 - 6:24am

I'm all for more 'lightweight' options when it comes to Java hosting. I've been using Jetty for a while now and I really like it so far, although you'll still need at least shared hosting for that. Aren't JSP's a bit closer to the idea behind things like PHP though?

Also note that you can already do things the other way around: run PHP on Java using Quercus (http://www.caucho.com/resin-3.0/quercus). No experience with that yet but it looks very interesting, and is supposedly quite performant as well.

Cheers,
Erik

David Lee replied on Fri, 2009/07/31 - 7:53am in response to: Erik Post

A JSP is not similar to PHP script, a groovy or jruby script is though.  JSPs aren't the problem, the container is the problem.  Shared isn't the problem either.  SCGI and FastCGI processes are shared.  Again, to have a reliable, shared Servlet container it takes a modified and restricted Servlet implementation, like GAE's. Consider why it has the restrictions it does. Some people, like me, just don't like PHPs syntax but do like everthing else about it.

I use Resin everyday with the GroovyServlet, but how many sites could I host on this box ?  Not many because i have no way to control the environment.  What happens after 10 different people upload 10 different versions of hibernate with their applications.  What happens in a PermGen error and a restart of the app server.  If I give each app, it's own JVM how many of those can run on the box ? It depends on the box, but I could definitely host more PHP apps on a similar box.  Hence, java hosting is always more expensive than PHPs.  It seems pretty common to be able to host a few hundred PHP apps on 1 non exceptional server. 

It may seem like Java has similar options until you try to prove it.  

I'm suggesting an environment really similar to PHP is possible with Groovy and a modified servlet api implementation that only processed groovy scripts.  An HTTP server would handle the rest. 

As a co-worker told me, it's a step backwards from what we have in current app servers.  I agree, but it's needed.

 

Rael G.C. replied on Fri, 2009/07/31 - 8:24am

"Shared isn't the problem either.  SCGI and FastCGI processes are shared."

Sorry, but this IS the problem. To run PHP as FastCGI you should use the FastCGI version, which take cares of shared libs. This is the main reason why PHP is so easy to host, you always know that are no conflicts between users.

David Lee replied on Fri, 2009/07/31 - 8:56am in response to: Rael G.C.

Control is the problem, or the lack of it is.

If there's an option to kill threads after X amount of time, and the security manager keeps you isolated to your own app, and prevents you from loading java.lang.Thread or swing classes or whatever, and the classloader will only load your groovy scripts.....you're pretty isolated and we can share a JVM. 

GAE does most of this, and I'm fairly certain that each app in the GAE does not get it's own JVM.

It's actually not that difficult to implement this.

 

Erik Post replied on Fri, 2009/07/31 - 10:22am

"A JSP is not similar to PHP script, a groovy or jruby script is though."

I was referring to the mix of markup and code that PHP uses, not JSP's implementation on top of servlets. However, I agree the latter is the big dealbreaker for certain (quick and perhaps somewhat dirty) types of development. I also agree that it would be great if JVM languages could cater to that crowd, too, if only to make the entry barrier to JVM-based (web) development somewhat less ridiculously steep.

The shared hosting requirement is a problem wrt the (comparatively enormous) hassle of setting up, vs. just uploading a couple of php pages and being done with it.

Robert Enyedi replied on Fri, 2009/07/31 - 10:53am

I wrote a post about one year ago which touches the deployment differences between PHP and Java (actually the JVM): http://java.dzone.com/news/open-source-web-applications-p-0

One important point to keep in mind is that a deployed but inactive PHP application does not consume any RAM or CPU, but only inexpensive disk space. This is the reason for the hosting pricetag difference. If a similar execution model could be replicated in the JVM then we could get a possibly even more competitive small JVM hosting.

Problem is the companies in charge with Java are completely focused on large deployments. And things got worse in this respect since last year (see the ongoing acquisition of Sun by Oracle). This leaves the door open for others, but unless you're the size of Google, it's very difficult to do it AND convice others to use it.

Guillaume Laforge replied on Sat, 2009/08/01 - 8:30am

For a lightweight Groovy-approach, you can have a look at Gaelyk which is a thin wrapper around Groovlets and Groovy templates.

David Lee replied on Sat, 2009/08/01 - 11:22am in response to: Robert Enyedi

They were great posts and the impetus for this one.  I spent a lot of time trying to strip down jetty to achieve an execution model similar to PHPs but I concluded it would be quicker to start from scratch.  Jetty is small but it's still a complicated piece of software.  Because of the JVM, I don't think we can really match PHPs model but it's possible to come close.  There is always some residual in a Java app because the GC does it's business when it wants to, but the GC does work. There will be considerably more memory used  but some thoughtful coding and jvm startup parameters should be able to keep the memory use in check.

David Lee replied on Sat, 2009/08/01 - 11:22am in response to: Robert Enyedi

They were great posts and the impetus for this one.  I spent a lot of time trying to strip down jetty to achieve an execution model similar to PHPs but I concluded it would be quicker to start from scratch.  Jetty is small but it's still a complicated piece of software.  Because of the JVM, I don't think we can really match PHPs model but it's possible to come close.  There is always some residual in a Java app because the GC does it's business when it wants to, but the GC does work. There will be considerably more memory used  but some thoughtful coding and jvm startup parameters should be able to keep the memory use in check.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.