Grails – the search is over

 And it is over for real. Imagine a full blown on-rails platform that…
- runs on almost any servlet container (Tomcat, Jetty, etc.);
- allows you to create web applications using a beautiful integration of Spring MVC…
- … using a nice dynamic language (Groovy) that is fully compatible with Java…
- … but not stopping you in any way to use Java itself if you like (for most functionalities);
- interacts with the database with the most impressive Hibernate integration (GORM) I’ve ever seen;
- makes it easy to create templates using a very simple yet powerful language (GSP);
- has a huge availability of plugins, from captchas, to optimizations, from LDAP to analytics;
- integrates a powerful testing suite;
- runs ‘convention-over-configuration’ for 99% of the features;
- the Eclipse plugins guide you during the development in the most useful way;
- its learning curve is gentle;
- it’s created and maintained by SpringSource!

Now, I’ve never been much satisfied by on-rails platforms, seriously, it’s not my world. Even more, being more a software engineer than a web engineer, my interests in that kind of products have always been kinda mild.
When I first met Grails (10 months ago) I was skeptical -as always- but it took me less than 1 hour to realize what was going on in my computer, and I was shocked. Everything was over the top. The persistence layer is SUPERB, the separation of the controllers and the UI is perfect as much as the languages needed to develop them (and their organization inside Grails). The time needed to understand all the basics? 1 hour.
Still, I HAD to start a test project and see how much my first feeling was correct and be certain this marvel of technology was ready to suffer the pains of a real full blown production environment. Folks, it really met my expectations. This thing… is amazing.

Of course it has some downsides, in 10 months I had my oh-oh here and there.
First of all, in production you might not need a super powerful machine to run it (unless your traffic needs it), but in development… well get ready to heat your processors and disk.
Secondly (by the time I’m talking, I’ve haven’t seen Grails 2 yet), sometimes the development environment simply stops working. “This is broken, this does not compile” you know, the kind of mysteries that makes you bang on the keyboard like a monkey. You just need to get in touch with Grails common oopses to fix that in an instant, but the very first times, it’s going to be a little troublesome. Note: this kind of issue are likely related to the Eclipse plugin, rather than Grails itself.

I’m no fanboy. I hate fanboys. But this framework makes me very close to one…

GO GRAILS! 

A good article about the garbage collector

Essential and very accurate article about JVM garbage collection by Alexey Ragozin:

http://aragozin.blogspot.com/2011/12/garbage-collection-in-hotspot-jvm.html

Java’s not old, just needing a grandson

For the ones saying Java is old and is following the path of Cobol: get lost. Java is and will be, for some long time, a bleeding edge in software programming.

Sure it’s changing it’s target, and it’s doing that naturally. In the early ’00s there were Java desktop application popping up anywhere. It was slow, not responsive at all and ugly. Things changed during the years, SWT became a super glam framework in Java desktop programming and I used it A LOT with good results (but can’t say pleasure). I agree there are far better languages and frameworks for the client side, but no matter what Apple says, Java is here and will stay.

But the truth is the best Java ecosystem is server side. J2EE applications rock the enterprise, servlet containers rock web applications.

Still, Java is getting old. Being old means being wise, having a huge background and being able to face almost any situation. It’s not the framework. It’s the language. And languages are subject to fashion, changing needs, will to improve.
Especially with this recent big interest in functional languages an mixed “compiled+interpreted” languages, Java is helplessly behind.
Reinventing a language (some people do…)  must be a beautiful experience. I never tried that and probably never will, but it must shake your world. Still, as my friend and researcher Francesco Zanitti told me yesterday (he’s working on much more advanced stuff compared to my today’s topic), theory and real world are so distant in computer languages some can get demotivated.

Java rocks, but is in need of a grandchild. A successor. A language that can take the hierarchy of Java and bring what’s been done so far to another level, adding new possibilities rather than limiting what’s available now to get to a new frontier. Some may say this limits the possibilities to improve, to invent, but the fact is this is not a contextual language, nor a scripting engine. I’m talking about a commercial language that has to be able to add spice to something that already works well. That can handle complexities that can scare the crap out of you. It doesn’t necessarily have to be “born from Java”, it can also come from elsewhere, but the fact stays: to obtain adoption, you have to pull current knowledge and wisdom out of Java.

If I had solutions to this dilemma, I wouldn’t be here writing. Still I have some major suggestions for you to extend your interests on what’s out there:

Scala is a very intriguing, elegant programming language. It integrates both object oriented and functional programming and can interact with Java pretty well, resulting a flavour that is, in my opinion, unique. The project is mature and the success stories are not few: one for all Twitter.

my pick:
Groovy  shares many things with Scala, also the syntax has a lot in common. Object oriented and functional programming work as one and the interaction with Java is absolutely surprising (no extra work at all). The learning curve is ridiculous because Groovy basically accepts all Java syntax and lets you learn what else it can offer. It’s not too elegant, nor too fast,  but incarnates beautifully what I meant in this article. The project is not fully mature in my opinion, but is endorsed by SpringSource and used as main language in the Grails web framework (that has many success stories).

I’m certainly missing some great tools. These are just two good languages I had the luck to work with directly and had fun with. I’ll be writing more about Groovy soon, but in the meantime, take your time to try them yourself, it’s worth it.

Good annotations: clean code

Annotations are a fantastic tool introduced in Java 1.5 that allows you do add some extra information to a class, method or field.
I thought of it lots of times, but I’m sure we all did: a class is a class, it does its stuff, it has its fields and methods, but it would be nice to add some extra information to trigger some events, in certain conditions. I mean, not variable, mutable, changeable info, just static stuff.
Let me do a very simple example. Image a stupid javabean dump function. It gets a generic bean, and prints the values returned by the getters (with the technique I explained in “Coffee Mug Reflections part 2″)

class RandomBean{
[...]
public int getAVal();
public int getBVal();
}

The function we’re talking about would print the results of getAVal and getBVal. Say, “1″ and “2″? Meaningless data. Even if we printed the methods name “getAVal: 1″ and “getBVal: 2″: useless. Even if the function name were “getArctanOfC”, the list of methods would be almost useless. How can we associate a comment to methods? Let’s annotate it!

Coffee mug reflections part 2 – Method objects

I’d like to spend a few words about Method object for many reasons. First, they’re cool. Second, if you come from the C/C++ world, you might have had the feeling that something was missing: function pointers.

In C/C++ function pointers are extremely handy tools to do lots of nasty stuff, and I must admit, before this was available in Java, I felt like something was missing.
Method objects are slightly different from function pointers and what I can say is… they’re way cooler. But before we have a look at how to use it, let’s proceed my way.

***Add on 2009/03/12 – thanks to Walter Milner***
What exactly is a Method object?
When you write a method, you rarely stop thinking about what exactly is the act of writing one. You’re writing a procedure that can freely interact with the object it’s enclosed in. In the method body you (and the compiler) make some some assuptions like:
when you write a=10; the compiler assumes that a is accessible from the method and that it’s a int. That’s obvious to you, but you shouldn’t ignore the importance of this fact. If a is private, nothing but the class methods are able to access its value. So your method is privileged.
A method object is an object that can trigger a method, knowing the class in which it’s defined, its name, and its parameters (in other words, its signature). The method can be static -and in this case it has no reference class- or not, and in this case you have to tell the method what class it’ll be reflecting on. If the method object changes the value of the class field a, you must let it know which object you want to alter.
Example:

class Stuff{
  private Integer a;
  public void setA(Integer val){
      a=val;
   }
}
//[...]
//...main...
Stuff first = new Stuff();
Stuff second = new Stuff();
//here's my reference
Method m = Stuff.class.getMethod("setA",Integer.class);
//I apply it to second
m.invoke(second,10);
//guess what's the value of a in second object...

***

Why the heck would I ever need them?
I can agree with you in some ways. There are very few things you can’t do in Java without them. One of them is the example we’ve seen in the previous chapter of this series. In that occasion we’ve used methods we didn’t even know they were there.
Another interesting setup is: method objects gives us a very fluent way to run methods or sequences of methods we choose runtime. Want an example of this? Say, image processing. A BufferedImage and a stack of things to do to it, build by a configuration file? You can do it traditionally? Alright, imagine now that everyone can produce a filter class ( extends ?) with only two rules: (1) each filterng method gets at least a BufferedImage and returns a BufferedImage (transformed); (2) every extra parameter is a java.lang type. This is getting a little tricky. Now, I agree with you this example is way too extreme, but see how the boundries of things you can do, change dramatically with this technique in your hands?

Coffee mug reflections part 1

You might not be that hardcore programmer to be a fan of it, but you certainly have at least heard about Java reflections.

This technology is available since Java 1.3 and it help us to do something extremely cute and, in some cases, tremendously useful.
It allows us to inspect the contents about classes and objects, without really know what class or object we’re handling. In fact that’s what it does: I don’t know you, so I ask you to tell me how you’re done.

I don’t like overwhelming theories, facts count, and as far as you understood the previous paragraph, you’re ready to read some examples. Let’s start with the very basics.