Sylva looked at my blog and pointed out I haven't posted in about two months. Since getting on Twitter and really starting to use it my blogging has evaporated. I didn't blog a lot before Twitter, but since Twitter I almost never blog.

So, what is it about Twitter that is so compelling for me? It's short. Posting is fast with Twhirl. I think well in short bursts. I don't feel compelled to develop a deeply thought out, well composed and edited blog post. In the past I've spent hours and hours writing blog posts on technical subjects. It takes a lot of time to get them right. Twitter is just so immediate.

Monday afternoon Ezra Isaac entered the world. My lovely wife Sylva did an amazing job. Ezra was born at home. Truly an amazing experience.

It's taken me years, but I finally got over import java.util.*;. First, I don't use an IDE. I know an IDE could manage my imports, but I'm not an IDE guy. So, for years I've managed my imports manually, or given up and done import java.util.* and felt guilty about it. Well, I'm over that, and I can give Groovy the credit. By default Groovy imports java.util.*. I've been using Groovy every day now for about a year and a half and the house is still standing, our code compiles, we haven't had name conflicts. Things work, and it's a lot easier.

I used to worry about name clashes and compilation speed, and other shiboleths spoken of around coder camp fires and in hushed tones. After all everyone "knows" that the * should be avoided. Well, I'm over it, import java.util.* is just fine with me. Now when I start a Java source file I almost always just add java.util.*.

Although Java isn't thought of as a dynamic language now a days, what with Ruby and Groovy being all the rage, Java does have support for dynamic features. (See my previous blog post on the subject and the solution I came up with.)

A Use Case for Dynamic Java

Currently I'm wrapping about a hundred EJB 2.1 LocalHome classes in DAO's, and having them transform local EJB entities into POJO's. Much of the code is largely boiler plate. Actually it's mind numbingly boiler plate. Here's a sample of wrapping a finder:

(Related article using this technique to "script" some Java objects: article.)

The following code quickly illustrates an issue with the Reflection API's in the Java language. At run time finding methods on classes requires that the types passed to Class#findMethod() exactly match those found in the method declaration. The JavaDoc and language spec refers to these as the "formal parameter types".

The issue is, I have a method that takes an A, and I have an object of B that extends A. If you run the following code it will fail, being unable to find the method.

You can learn something every day. That's what is so nice about being a software developer.

Today I was looking at some Grails code, seeing how some of the metaprogramming features of Groovy are used in the framework. After poking around I decided to look at the ServicesGrailsPlugin to see how the automatic wiring of services was done, and ran across the following code:

def doWithSpring = {
  application.serviceClasses.each { serviceClass ->
      def scope = serviceClass.getPropertyValue("scope")

    "${serviceClass.fullName}ServiceClass"(MethodInvokingFactoryBean) {
      targetObject = ref("grailsApplication", true)

Although talk about multiple languages running on the JVM has grown over the past few years, the reality of it really hit home with me this morning. I turned to one of my employees who has been doing JVM development for me since April of last year. The interesting thing is probably 95% of the JVM work he has done isn't in Java, it's in Groovy. Here's to the multi-language Java platform and a thank you to those developers who are making it a reality.