The Grail of Java Web Development

Almost a year ago, in a post on metaprogramming, I announced that I would spend a few lines on my experience with Grails. I must tell you why I needed it: I wanted to develop some quick-and-dirty R&D Web prototype for my former employer, and also another one for my own pet project (a bleeding edge social web application, more later...).

I am a java fellow, not too keen on web programming (yes, I have done J2EE, servlets, a bit of Spring, and all that jazz, but my core interest is algorithms dev, not web architectures, plus patience is most definitely not my chief virtue), thus I needed something that would get me going real fast.

Rails? yes, but I had no time to learn Ruby well enough, and moreover I had some java code I wished to reuse, without any further ado.

The choice was obvious: Grails.

I have got to say that the very first minutes were truly blessed: seeing an entire web app coming out of nowhere was extremely gratifying. Customization? Well, it was a bit of a pain, to tell you the plain truth. Groovy is easy, but is still another language, and things are not entirely trivial when it comes to going beyond a simple CRUD app. However, all in all, big thumbs up.

The best part is, there are many plugins available.

You need security? ACEGI plugin.

You need search? Worry not, there is a searchable plugin based on Compass and Lucene.

Do you want to do some fancy Ajax stuff? Plenty of choice. For instance, the GWT plugin.

Bottom line: you have (most of) the tools you need.

Is Grails scalable enough for a true enterprise app? Some say yes (I tend to believe them), some say no, but fact is, I do not know yet for sure (I''ll tell you in a while). What I do know is, if you want to develop some web prototype at the speed of light (almost), and you do not want to go out of your familiar java turf (why should you?), stick to Grails.

PS I have already written on Graeme Rocher's blog this one, but I am going to repeat it here and now: as a social web researcher/developer, I would love to see some plugins dealing with the OpenSocial API, or perhaps a FaceBook API plugin, i.e. some way to get a template of a social web app right off the shelf, as it were. As I am a big believer of the programmable social web, I think this step would skyrocket Grails to another dimension of adoption and success. Hopefully something along those lines will be available soon.

The Imminent Rise of the Metaprogrammer

Caveat Lector: I shall indulge here in that most futile of all exercises, predicting the future. Allow me to put on the cloak of Merlin (not to mention his infamous pointed hat), look at the crystal ball, and solemnly proclaim, announce and declare

The Imminent Rise of the Metaprogrammer.

You have guessed right: a metaprogrammer is someone who develops metaprogramming code (metacode), i.e. code that creates and/or modifies programs (included, perhaps, itself).

Metaprogramming is by no means a new game: folks in functional programming (remember LISP?) have been writing metacode for many years. However, it is only quite recently that metaprogramming paradigms have percolated down to the world of mainstream programming (I am not counting in compilers, debuggers, etc.). Languages such as Python and Ruby, and to a lesser extent the new Java with annotations, have built-in metaprogramming capabilities.

Now, what kind of metacode can one write? The possibilities are, of course, endless. Nevertheless, for the sake of simplicity, we can classify metaprograms into two main categories, static and dynamic (for reference, check this synthetic presentation by Aussman and Kessler), somewhat mirroring the distinction compile time versus run-time: in the static category a metaprogram creates, edits. inspects some code, whereas in the dynamic model the same happens while the underlying program runs.

Rails is a successful example of static metaprogramming: it generates a template web project out of thin air (incidentally, I note in passing that there is a Java version of Rails, known as Grails. I shall talk on my experience with Grails in a future posting). There is no question in my mind that static metaprogramming will make further strides in the very near future.

However, my interest and hopes lean more toward the second category. I dream of a new generation of enterprise programs that modify themselves at run-time, to accommodate the ever-changing, often erratic business needs. Those programs will use both pillars of reflection, introspection, to see themselves, and introcession, to adapt and evolve.

In spite of the promises, and the fact that languages like Ruby amply provide the plumbing for sophisticated dynamic metaprogramming, so far (at least to my knowledge) we have only whetted our toes.

So, what do we need to get there? My gut feeling is that, aside the obvious step of educating mainstream programmers to the benefits (and potential marvels) of metaprogramming, two more things are necessary:

• a single rock-solid example of applied dynamic metaprogramming


• tools and environments to ease the work of prospective metaprogrammers

Some brave visionary soul must rise up to the challenge: any paladin out there to pick up the glove?

PS Conjecture: the two bullets above will pop up together in a single breath-taking sweep