« April 2007 | Main | July 2007 »

May 2007 Archives

May 2, 2007

Groovy and (Dynamic Dispatch|Multiple Dispatch|MultiMethods): A Simpler Example

So my last entry on static vs. dynamic dispatch and how it interacts with method overloading got caught up in some weird rules relating to the automatic promotion of primitive types. Now I have concocted an example that runs, unmodfied, in both Java and Groovy. Caution: This is a code heavy post.

public class BabyColors {
    
    String color(Boy b) { return "Blue"; }
    String color(Girl g) { return "Pink"; }
    String color(Baby a) { return "Green"; }
    
    String whatColor(Baby a) { return color(a); }
    
    public static void testDirect() {
        BabyColors bc = new BabyColors();
        Baby a = new Baby();
        Baby bb = new Boy();
        Baby bg = new Girl();
        Boy b = new Boy();
        Girl g = new Girl();
        bc.color(a);
        bc.color(bb);
        bc.color(bg);
        bc.color(b);
        bc.color(g);
    }
    
    public static void testIndirect(int iterations) {
        BabyColors bc = new BabyColors();
        Baby a = new Baby();
        Baby bb = new Boy();
        Baby bg = new Girl();
        Boy b = new Boy();
        Girl g = new Girl();
        bc.whatColor(a);
        bc.whatColor(bb);
        bc.whatColor(bg);
        bc.whatColor(b);
        bc.whatColor(g);
    }
    
    public static void main(String[] s) {
        BabyColors bc = new BabyColors();
        Baby a = new Baby();
        Baby bb = new Boy();
        Baby bg = new Girl();
        Boy b = new Boy();
        Girl g = new Girl();
        System.out.println("Indirect -------");
        System.out.println("unknown   - " + bc.whatColor(a));
        System.out.println("baby boy  - " + bc.whatColor(bb));
        System.out.println("baby girl - " + bc.whatColor(bg));
        System.out.println("     boy  - " + bc.whatColor(b));
        System.out.println("     girl - " + bc.whatColor(g));
        System.out.println("Direct ---------");
        System.out.println("unknown   - " + bc.color(a));
        System.out.println("baby boy  - " + bc.color(bb));
        System.out.println("baby girl - " + bc.color(bg));
        System.out.println("     boy  - " + bc.color(b));
        System.out.println("     girl - " + bc.color(g));
    }
}

class Baby {}
class Boy extends Baby {}
class Girl extends Baby {}

Seems simple enough, rather than using virtual methods to store the information as to what color a baby blanket you would buy for a co-workers new baby. If it's a buy, you get blue. If it's a girl, you get pink. Not sure? Green. The Baby color class keeps this information because, after all, babies don't know what color blanket they should have. You throw an old beach towel on some of them when they sleep and they will be happy (not that I've done this...).

Ok, back to the post. What will Java output? Think about this before you scroll down too far. Java looks a the types it can prove at compile time and fixes the method it will call based on the type the variable is claiming to be, not the type it actually is at run time. So when we filter all of the calls to color through an intermediary that only accepts Baby objects it will treat them as thought that's all they can ever be, Babys. Even if the compiler knows at the time that the call is being processed that the type must be a boy or a girl, it forgets all of that information when it goes into the whichColor method. Now when the color method is called directly, in the two instances where the type of the object is declared to be a Boy or a Girl the gender specific variant is called.

Now there is the dynamically typed method dispatch (or multiple dispatch, or multimethods) which on current generation JVMs is about a thousand times slower. Java itself doesn't support this invocation style, but Groovy supports this style as the only style of method invocation. At runtime when you invoke a method on an object, the actual instances of the types of the object are inspected and compared against all of the available overloaded method signatures. Hence regardless of the declared type of the object, the overloaded method that is selected will be closest to the particular class type and interfaces types of the passed in object.

So how do the languages process the above code? Well Java does the type safe thing and always buys green, unless it know it must be a boy or a girl.

Indirect -------
unknown   - Green
baby boy  - Green
baby girl - Green
     boy  - Green
     girl - Green
Direct ---------
unknown   - Green
baby boy  - Green
baby girl - Green
     boy  - Blue
     girl - Pink

Groovy on the other hand, peeks into the babies diaper and buys the appropriate color, unless it can't do that.

Indirect -------
unknown   - Green
baby boy  - Blue
baby girl - Pink
     boy  - Blue
     girl - Pink
Direct ---------
unknown   - Green
baby boy  - Blue
baby girl - Pink
     boy  - Blue
     girl - Pink

May 8, 2007

JavaOne and JavaFX: I Think I've Been Here Before

This morning I had a real strange sense of Deja Vu. But not quite.

Back in the summer of '99 I had a month off between classes at college, and I decided to not get a job but instead try this new 'open source' thing that I had been reading so much about. The idea was to take some other technology, and do it with a free license. Kind of line Linux did with Operating Systems. My target? JavaServer Pages. It seemed like an interesting problem. I wrote up a JavaCC script to parse out the grammer, and then I wired in some code generation to create a servlet. Entertaining summer hack, or more like a spring hack since my developemnt kinda kit a roadblock quickly after it was released. You see two days later Sun announced the Jakarta Project.

"Holy cow I just wasted several weeks of my life!" was my initial reaction. But it wasn't so bad in the end. It took nearly six months to release the code, and in the end I revved my release once more to support TagLibs, and then I ultimately joined up with the Jakarta project in the end. I also found me a wife which quickly curtailed my contributions to Jakarta.

Fast forward eight years. About a month ago I was accepted to Groovy as a committer, mostly on account of my patch submissions for the SwingBuilder portion. I've done some damage recently, mostly relating to refactoring. And then this morning, Sun announces JavaFX Script (which is basically a rebranded F3). Dude, I could have spent more time in the last few months playing Halo or building lego towers with my son!

But this isn't quite the same, JavaFX is a total niche play right now (the niche being Flash and SilverLight). I also find it interesting that the FAQ specifically calls out Groovy to justify itself. But I don't see this as a zero sum game. Both can survive, and even thrive. And one way or another I see myself dribbling into various projects here and there because I find it as entertaining as playing Halo (but it ranks below quality time with the boys).

It's not like I'de turn down a job to hack at Groovy full time, I mean I see value in monetizing your hobby (I'm not saying I'm looking for a new job. I'm also not not saying I'm looking for a job either). But corporate sponsorship or not projects like this will continue and grow because deep down inside, people like me like to hack at code.

May 11, 2007

True Story [;]

The other night my wife and I had put our two sons down for the night (no small task, one is six months old and the other two and a half years). Since we managed to get them down early we finished watching survivor long before our bedtime, so I was able to grab my computer and work on some code I had been thinking about most of the day. My wife, having had some exposure to C programming in her Civil Engineering coursework, looked over at my open windows and stated "Gobbeldy-gook gobbeldy-gook gobbeldy-gook semi-colon."

My response was "oh no, I don't need the semi-colons. I'm coding in Groovy!"

May 18, 2007

WS-ActiveGroovyFX Script.Net 2.0!

Groovy can do anything! Groovy can save the world! I am publicly announcing my intent to look into opening a JSR for WS-ActiveGroovyFX Script.Net 2.0! Not to be confused with WS-ActiveGroovyFX Mobile.Net 2.0!, that one has a REST based interface and no AJAX support but the marketing folk felt that keeping the WS- prefix would provide implicit credibility to the enterprise mobile crowd that carries Black Beries and Treos.

Yea, It's not yet too late for Groovy FX, but it's not too early to mock it either.

May 21, 2007

JSR-295 Binding Builder for Groovy

In response to my recent post about swing data binding and groovy I am pleased to let everyone know that I've been doing more than making snarky remarks about <Foo>FX and causing grief constructive discussion on the developers list. I've actually implemented something. Ultimately for a first pass I decided to wrap the 0.5 release of the beansbinding project for JSR-295. Well, at least as much as I've found demo code for online. It's kind of weird writing code for a JSR that has released working code but hasn't posted a public review of their API. I'm talking about Beans Binding not Groovy. (Oops, there goes the snarky remarks again, of course released working code preceeded the Groovy JSR.)

In working with the code for beans bindings I see why they decided to go with EL notation in the naming of the source and target properties. It has to do with the ability to stack up the various bean references and make a 'property path' of observable beans, where if a change is observed in any of the beans along the path an update will be triggered. While my approach was a little more simplistic than this, the JSR approach has the advantage of a simplified mental model for properties, you don't need to be a swing wizard knowledgeable about all of the events, or the model objects that actually fire the events. More like a data modeling DSL and less like a Swing API in the end.

Anyway, to get at it you are going to have to download the source from svn and build the beansbinding module. It's not soup enough to make release jars IMHO, perhaps closer to Groovy 1.1 if GROOVY-1884 gets the blessing of the despots. In fact the current demo relies on the @BoundProperty patch I just mentioned. It may also get rolled into the SwingXBuilder project from Google's Summer of Code. For a code sample you can look in the Groovy Wiki.

In a later blog I will go into some of the design decisions, but I'll just leave it by saying that I think the nested nature of the JSR-295 API makes it look and work great in a Groovy builder.

About May 2007

This page contains all entries posted to ... And They Shall Know Me By My Speling Errors in May 2007. They are listed from oldest to newest.

April 2007 is the previous archive.

July 2007 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33