W.r.t your example: all the other 'pretenders' (JRuby, Jython, etc) can do
something similar, none of them can then further extend the GUsesJ class
with another Java class (ie J -> G -> J -> J -> G -> J, etc.)

yes, did I make this point before, it can all be compiled to bytecodes and so are equal within the JVM.

This leads me to the recent announcement by the Mono Project (cross platform .NET) about their Version 2.0 release. I used Mono a few years back to allow a new Java Windows server product to have a fast result on a fax delivery end point for scanned images (using faxcomlib). C# made accessing the operating system a doddle, plus the C#/.NET high level abstraction meant that a complex task was reduced to a days coding. It took as long to suggest the technology and get a Java shop to accept that results were better than third party licences eroding profits on a purists "Java only" solution.

OK I mention Mono because, even though a google search for Groovy + .NET doesn't pull much up, it should be quite feasible to have Groovy supported by the IKVM, i.e. running in a CLR on a par with C# code! Now I enjoyed coding in C# and it might be up to discussion as to whether Groovy has a place in the .NET space!

Kirill Grouchnikov collects interesting Swing-related links every week. He was kind enough to link to my first post, and rightly pointed out that in my Java example, I'd make some errors. As he said,

"... the Swing example is not the best one, violating the EDT rules, working with the content pane and not centering the frame in the monitor, and the author admits some of these points."

Let me say up front that I'm grateful for his comments. That's how I learn. Part of the reason I post here (other than just the joy of sharing what I've learned) is to find out what I've been doing wrong, or, if I'm okay, what I can do better. One of the principles I live by is, "I'm often wrong, but I don't stay wrong." So keep those cards and letters coming. :)

Here's the code that Kirill addressed:

[sourcecode language="java"]
import java.awt.Container;
import java.awt.GridLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JTextField;
import javax.swing.WindowConstants;

public class EchoGUI extends JFrame {
private JTextField input = new JTextField(20);
private JLabel prompt = new JLabel("Input text: ");
private JLabel echo = new JLabel("Echo: ");
private JLabel output = new JLabel();

private Container cp = this.getContentPane();

public EchoGUI() {
super("Echo GUI");
cp.setLayout(new GridLayout(0,2)); // 2 cols, as many rows as necessary

cp.add(prompt);
cp.add(input);
cp.add(echo);
cp.add(output);

input.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
output.setText(input.getText());
}
});

this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
setSize(300,100);
setVisible(true);
}

public static void main(String[] args) {
new EchoGUI();
}
}
[/sourcecode]

First, Kirill was right about my working with the content pane rather than adding my components directly to the JFrame instance. I remember way back in the Java 1.0 days (holy AWT, Batman), you added components directly to the instance of java.awt.Frame. Then, when Swing came along, you weren't supposed to do that any more. Instead, you added to the content pane in front of the JFrame. That held true for Java 1.2, 1.3, and 1.4. Finally, in Java 1.5, you could go directly to the JFrame again, because now adding to the frame redirects to adding to the content pane. I need to retrain myself to do that.

Here is a link to a good post that explains why everything changed and then changed back.

Another of Kirill's comments was that I didn't center the frame on the monitor. I used to do that via code like
[sourcecode language="java"]
Toolkit tk = Toolkit.getDefaultToolkit();
Dimension screenSize = tk.getScreenSize();
[/sourcecode]
From that I can get the width and height of the screen, and then using the width and height of the frame I can center everything. I can do that, but here it seems a bit like overkill.

Finally, we come to the real issue, which is also the subject of this post. As he said, I violated the EDT rules, and that's bad.

Arguably Rule #1 of Swing GUI's is "Only update GUI Elements in the Event Dispatch Thread (EDT)." From what I gather from frequent posts about that issue across the web, this is an error as common to Swing developers as forgetting to close database connections is when writing JDBC code. And again, this is one of those situations in Swing where the rules have changed multiple times, although maybe it's more accurate to say that the rule hasn't changed, but the way to implement it has.

First, some quick background. Every Swing program involves multiple threads. First, there are the initializing threads, which start up the GUI. In a Java application, that's the main method. Then there is the Event Dispatch Thread, which maintains an Event queue that handles all the GUI updates, and finally there are any background threads that are used to manage long-running processes. If you make sure that non-GUI processes are off the EDT, then the GUI will remain responsive while the application is doing other work.

As of JDK 1.6, the standard library now has the class javax.swing.SwingUtilities, which contains the methods invokeLater and invokeAndWait. According to the concurrency lesson in the Swing tutorial, the proper way to create a GUI is
[sourcecode language="java"]
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
@Override
void run() {
\\ ... instantiate the GUI ...
}
);
}
[/sourcecode]
The invokeLater method creates the Runnable object and gives it to the EDT to add to the event queue. The alternative method invokeAndWait does the same thing, but it blocks until the task is completed.

What does Groovy bring to this picture? As usual, Groovy simplifies matters. Groovy adds three helpful methods to groovy.swing.SwingBuilder: edt, doLater, and doOutside.

What do they do? One of the best things about using an open source API is that, well, you have access to the source code. For the edt method, the implementation looks like (paraphrased):
[sourcecode language="java"]
public SwingBuilder edt(Closure c) {
if (SwingUtilities.isEventDispatchThread()) {
c.call(this)
} else {
// ...
SwingUtilities.invokeAndWait(c)
// ...
}
}
[/sourcecode]
In other words, if we're in the EDT already, invoke the closure. If not, call invokeAndWait to get to the EDT.

Likewise, for doLater:
[sourcecode language="java"]
public SwingBuilder doLater(Closure c) {
// ...
SwingUtilities.invokeLater(c)
// ...
}
[/sourcecode]
and for doOutside:
[sourcecode language="java"]
public SwingBuilder doOutside(Closure c) {
// ...
Thread.start(c)
// ...
}
[/sourcecode]

So what's the bottom line?

• edt: use the EDT through invokeAndWait
• doLater: use the EDT through invokeLater
• doOutside: create a worker thread and start it (off the EDT)

Incidentally, SwingBuilder also has a build method specifically designed to construct the GUI. How does it handle threading?
[sourcecode language="java"]
public static SwingBuilder build(Closure c) {
SwingBuilder builder = new SwingBuilder()
return builder.edt(c)
}
[/sourcecode]
That's the whole method -- create the buillder and then build the GUI on the EDT, synchronously. That's why all of our previous examples of SwingBuilder, which only used the build method on the builder, ran correctly. They're doing the initial construction on the EDT, as they should.

Ultimately, practical examples of Groovy Swing code uses actions that take advantage of these methods, as in
[sourcecode language="java"]
swing.actions() {
action(name:'myMethod') {

doOutside {
model.prop = textField.text
// ... other model property updates ...
def ok = someLongRunningService(model)

doLater {
model.ok = ok
} } } }
[/sourcecode]

And there you have it. Grab the data and update the model outside the EDT, then run the long running application. When it's finished, update the GUI in the EDT. (Note that here we're updating the model in the EDT because the model properties are bound to the GUI elements, so changes in model properties will result in a GUI update. See my previous post in this series for details.)

From here it's only a short step to Griffon.

This time I found a nice blog entry about Grails and an overview of must-reads and resources for developing your first grails website: http://blog.saddey.net/2008/10/11/grails-links-from-my-first-week-with-grails/

Looks worthy for a closer investigation of grails. Well, I wanted to develop my own grails site as a little private side project since summer, but I still have no time. I first need to get my infrastructure right, as my 2 1/2 year old notebook is getting buggy and slow and needs a replacemt and that needs money, which I don't have (not even banks have money nower days...). Maybe next three month I'll get new hardware and energy for my side projects. At least I hope so.

Greetz, GHad

Groovy makes the sometimes verbose Java more palatable. But more importantly, it is very easy to mix the two and in a far more advanced way than one could have ever done with TCL and C/C++.

Sometimes a simple example is all that one needs to get the idea. Here is that example.

Edit a simple java base class, something obvious like

$ cat JBase.java

public class JBase {
  public void doIt() {
    System.out.println("Java: JBase");
  }

  public static void main(String [] args) {
    JBase jbase = new JBase();
    jbase.doIt();
  }
}

Create your bytecode (JBase.class)

$ javac JBase.java

Edit a Groovy script to use the above

$ cat G_uses_J.groovy

JBase jbase = new JBase()
jbase.doIt()

And create your Groovy bytecode (G_uses_J.class)

$ groovyc G_uses_J.groovy

And finally run it

$ groovy G_uses_J
Java: JBase

Hey presto. I think you will get the idea, the two languages can be mixed up much more than a simple example will show, but let me spell it out though, "Mixing scripting with Java is dead easy, and if you use Java then you can already use Groovy!"

Give it a go, make your product more customizable at client sites!

ADDENDUM: Thank you Bob for this very important point. Call our groovy code directly from Java like so (note the groovy library). It is indeed all JVM bytecode compatible.

    java -classpath .;c:/Dev/groovy-1.5.7/embeddable/groovy-all-1.5.7.jar G_uses_J
Java: JBase

If I were to learn a new language, or Java from scratch again in the University, This way of packaging would make a HUGE difference!

What next?

The sweet spot for using Groovy is

• Familiarity to Java developers. Paste in your favorite Java code, and it will compile
• Java classes are imported and used as normal
• Strings, Files and many other standard classes have been extended with often-used functionality
• Handling stuff on the file system - copying, deleting aso
• Parsing XML in a nice DSL
• Simple SQL/JDBC
• Binding together a Java application

Resources

• Groovy online Documentation
• Groovy In Action - Teh Bible
• Simple introductionary video from JavaZone
• Advanced usage of Groovy video from JavaZone

Performance improvements

Compilation and runtime performance were the main focus of this release. The developers claim improvements of up to 5 times, although I could not attest it.

Multiple Assignments

This is called tuples in some programming languages. It is actually a pretty useful concept:

[sourcecode language="java"]
def a, b

(a, b) = 1..2

assert a == 1
assert b == 2

// variable swap

(a, b) = (b, a)

assert a == 2
assert b == 1
[/sourcecode]

You can even use it to return multiple values from a method, something I have been missing from Java for a while.

if Returns

if statements may now be used for implicit returns:

[sourcecode language="java"]
// Groovy 1.5

def max(a, b){

if (a > b)
return a

else
return b
}

// Groovy 1.6

def max(a, b){

if (a > b) a else b
}
[/sourcecode]

Grape

The Groovy Advanced Packaging Engine automatically downloads dependencies at runtime, allowing programs to be distrubuted wihtout additional JAR files. See http://groovy.codehaus.org/Grape for details.

AST Transformations

Think of AST Transformations as compile-time meta-programming. Some sample transformations include @Singleton, @Immutable, @Delegate, @Lazy, and @Newify.

A instalação é bastante simples: baixe, descompacte, configure as variáveis de ambiente, e atualize seu PATH. O único pré-requisito é ter o Java SDK 1.5 ou superior instalado no computador. Certifique-se que a variável de ambiente JAVA_HOME esteja configurada de acordo com sua instalação Java:

[sourcecode language='java']
$ export JAVA_HOME=/Library/Java/Home
[/sourcecode]

Primeiro, baixe as distribuições a partir de http://groovy.codehaus.org/Download e http://grails.org/Download, descompacte os arquivos:

[sourcecode language='java']
$ unzip groovy-binary-*.zip
$ ln -s groovy-* groovy
$ unzip grails-bin-*.zip
$ ln -s grails-* grails
[/sourcecode]

E configure as variáveis de ambiente GROOVY_HOME e GRAILS_HOME:

[sourcecode language='java']
$ export GROOVY_HOME=[...]/groovy
$ export GRAILS_HOME=[...]/grails
[/sourcecode]

Se for conveniente, atualize PATH e CLASSPATH:

[sourcecode language='java']
$ export PATH=$PATH:$GROOVY_HOME/bin:$GRAILS_HOME/bin
$ export CLASSPATH=$CLASSPATH:$GROOVY_HOME/embeddable/groovy-all-[...].jar
[/sourcecode]

Para testar a instalação, digite groovy -v e grails:

[sourcecode language='java']
$ groovy -v
Groovy Version: 1.5.7 JVM: 1.5.0_16

$ grails
Welcome to Grails 1.0.3 - http://grails.org/
[/sourcecode]

E pronto, é só isso. Tanto o Groovy quanto o Grails incluem suas respectivas dependências. O Grails inclui, para propósitos de desenvolvimento, até mesmo servidores Web (Jetty) e de banco de dados (HSQLDB) além do Spring e do Hibernate. Não é necessário instalar nenhum outro programa, como Tomcat ou MySQL, apenas para começar a trabalhar. Na verdade, a distribuição do Grails inclui os arquivos Groovy necessários. Portanto, não precisamos manter uma instalação dedicada do Groovy se quisermos usar apenas o Grails.

The installation is simple and straightforward: download, unpack, set the environment variables, and update your PATH. The only requirement is to have the Java SDK 1.5 or higher installed on the machine. Make sure the JAVA_HOME environment variable matches the Java installation:

[sourcecode language='java']
$ export JAVA_HOME=/Library/Java/Home
[/sourcecode]

First, download the binary distribution from http://groovy.codehaus.org/Download and http://grails.org/Download, unpack the files:

[sourcecode language='java']
$ unzip groovy-binary-*.zip
$ ln -s groovy-* groovy
$ unzip grails-bin-*.zip
$ ln -s grails-* grails
[/sourcecode]

And set the GROOVY_HOME and GRAILS_HOME environment variables:

[sourcecode language='java']
$ export GROOVY_HOME=[...]/groovy
$ export GRAILS_HOME=[...]/grails
[/sourcecode]

It might be convenient to update PATH and CLASSPATH:

[sourcecode language='java']
$ export PATH=$PATH:$GROOVY_HOME/bin:$GRAILS_HOME/bin
$ export CLASSPATH=$CLASSPATH:$GROOVY_HOME/embeddable/groovy-all-[...].jar
[/sourcecode]

To test our installation, type groovy -v and grails:

[sourcecode language='java']
$ groovy -v
Groovy Version: 1.5.7 JVM: 1.5.0_16

$ grails
Welcome to Grails 1.0.3 - http://grails.org/
[/sourcecode]

And that's it. Both Groovy and Grails come with all dependencies included. Grails even includes a Web server (Jetty) and a database server (HSQLDB) for development purposes, along with the Spring and Hibernate frameworks. No need to install any third parties, such as Tomcat or Mysql, just to get started working. In fact, the Grails distribution includes the required Groovy files, so we don't have to keep a stand-alone Groovy installation if we only want to work with Grails.

(Click through to flickr for access to more detailed larger size.) Books (not counting the Hobo bookcase) include Dharma Bums, Be Here Now (and see also the Be Here Now carpet), The Lazy Man's Guide to Enlightenment (my favorite obscure hippie philosophy book), Hippies from A to Z (lols), and (on the ground slightly under a crate) the first annual Swimsuit Edition of High Times. Various T-shirts in the T-shirt vendor, two classic Arcadia Asylum freebie vendors with very cool (if high-prim) hobo things, a lovely colorful mushroom by Sabrinaa Nightfire (who was kind enough to let me give that away too), a couple of meditation balls, and a freebie psychedelic chair. What more could one want? Well, drugs of course, but there are lots of those in the other booths nearby. :)

Note: I seem to have been in SL quite a bit less lately (there may even have been a day when I didn't get inworld at all!). Not taking a hiatus or anything, and definitely not a reflection on any of many beloved v good friends there. Just feeling a sort of early-fall hibernating mood, I think, and also a huge unpaid sleep debt. :) I imagine I'll be back to more or less my old ways before long. So don't worry!

The code for the Echo GUI currently consists of:

[sourcecode language="java"]
import groovy.swing.SwingBuilder
import javax.swing.WindowConstants as WC

SwingBuilder.build() {
frame(title:'Echo GUI', size:[300,100],
visible:true, defaultCloseOperation:WC.EXIT_ON_CLOSE) {
gridLayout(cols: 2, rows: 0)
label 'Input text: '
input = textField(columns:10,
actionPerformed: { output.text = input.text })
label 'Echo: '
output = label()
}
}[/sourcecode]

The closure assigned to the actionPerformed property transfers the input from the text field to the output label.  In order to make that happen, both the field and the label were given names that could be referenced inside the closure.

Groovy 1.5+ includes a method called bind, which works with bound properties in the ancient JavaBeans specification.  For those whose only exposure to JavaBeans is through POJO's on the server side, the original JavaBeans framework was designed to support GUI builders.  It looked and felt much like building GUIs in VB, in that you dragged these "beans" onto a palette, hooked them together, and set the values of their properties.  It was a way of writing Java user interfaces without writing any Java code, at least until you wanted the various widgets to actually do something.

I remember back around 1998, I convinced my boss at the time to purchase Sun's proposed IDE based on beans.  I think it was called Sun Java WorkBench, or something like that.  It cost about $99, and it came with beans that you could drag and drop, and you could add your own jar files full of beans as well.  While it looked pretty cool, you didn't have the source code for any of the beans, which limited their usefulness.

Java on the client side didn't really take off, and the market for the IDE certainly didn't pan out.  I do remember that the JavaBeans specification -- written largely to support the client-side development model -- brought us many aspects of Java that we take for granted now.  My first encounter with serialization came from there, as well as reflection, though they used the extremely awkward name introspection for it.  In addition to implementing java.io.Serializable, JavaBeans according to the spec were also supposed to have default constructors and the now-infamous naming convention for getters and setters for all the properties.  Actually, providing a getter method was sufficient to define a property of a JavaBean.

The spec also referred to various types of properties, like bound and constrained, and JavaBeans were also supposed to implement the PropertyChangeListener interface.

Very few Java programs were actually written using those JavaBeans, and the expected third-party market in JavaBeans libraries never seemed to develop.  I seem to recall that there were a couple of success stories (wasn't IBM's VisualAge for Java supposed to be written using the original JavaBeans spec?), but mostly the whole technology went away.

It wasn't until a few years later that JavaBeans re-emerged, as the way to get Java code out of JavaServer Pages.  Sun's Model 1 architecture consisted entirely of JSPs and JavaBeans, with no explicit servlets anywhere.  Model 2 changed all that by using servlets for controllers, but that came later.  By then, though, people used what we now call POJO's for model classes, and you were still supposed to make your beans serializable, but all that stuff about property change listeners was largely ignored.

Groovy gives us a chance to use JavaBeans as model classes in an especially easy way.  First, here's an illustration of a simple GUI that uses the bind method in Groovy.

[sourcecode language="java"]
import groovy.swing.SwingBuilder
import javax.swing.WindowConstants as WC
import java.awt.BorderLayout as BL

SwingBuilder.build() {
frame(title:'Binding to Slider', pack:true, visible:true,
defaultCloseOperation:WC.EXIT_ON_CLOSE) {
panel(constraints:BL.CENTER) {
slider(id:'sl')
}
panel(constraints:BL.SOUTH) {
label 'Slider value: '
label(text:bind(source:sl, sourceProperty:'value'))
}
}
}
[/sourcecode]

Here we're taking advantage of the fact that all Swing widgets extend Component, which means they support property change listeners.  In this case, we have a slider with a property called value.  The bind method assigns the text of the label to the value property of the slider.  Dragging the slider immediately updates the label.

This is seriously cool, and means that the Echo GUI shown above can be made even more responsive by replacing the actionListener by binding the output label directly to the input text field.

[sourcecode language="java"]
import groovy.swing.SwingBuilder
import javax.swing.WindowConstants as WC

SwingBuilder.build {
frame(title: 'Regular Binding (Groovy)', size: [300,100],
visible:true, defaultCloseOperation: WC.EXIT_ON_CLOSE ) {
gridLayout(cols: 2, rows: 0)
label 'Input text: '
textField(columns:10, id:'tf')
label 'Echo: '
label(text:bind(source:tf, sourceProperty:'text'))
}
}
[/sourcecode]

The result is that now, any characters typed into the text field are immediately transferred into the label. Deletes work the same way. The text in the output label is bound to the value of the input text field.

While this is interesting and even useful, a true model-view-controller architecture wouldn't always bind widgets to other widgets. Instead, input values would be transfered to a model class, and then the model values would be sent to the output view. What we need, therefore, is a way to bind the view elements to an actual Java bean.

If this was Java, we would introduce a class that supported property change capabilities. Consider such a model class in Java:
[sourcecode language="java"]
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;

public class Message {
private String text;
private PropertyChangeSupport pcs = new PropertyChangeSupport(this);

public String getText() {
return text;
}

public void setText(String text) {
pcs.firePropertyChange("text", this.text, this.text = text);
}

public void addPropertyChangeListener(PropertyChangeListener listener) {
pcs.addPropertyChangeListener(listener);
}

public void removePropertyChangeListener(PropertyChangeListener listener) {
pcs.removePropertyChangeListener(listener);
}
}
[/sourcecode]
The Message class has a single property, called text. It also relies on the PropertyChangeSupport class to enable it to add and remove property change listeners. When the text property is changed, the setText method fires a property change event to all the listeners, where the arguments to the firePropertyChange method are the name of the property, its old value, and the new value.

How does Groovy simplify this? The key is the @Bindable annotation, which is currently only in Groovy 1.6 beta 2. Fortunately, that version is included in Griffon, though I did go to the trouble to download and rebuild it myself (a post for another time).

Using Groovy 1.6b2, here's the equivalent Groovy bean:
[sourcecode language="java"]
import groovy.beans.Bindable

class Message {
@Bindable def text
}
[/sourcecode]
Seems almost unfair, doesn't it? Add an annotation to the field, and you're done. It's hard to get much simpler than that.

Now all you need is a listener. In Java land, the GUI would use something like:
[sourcecode language="java"]
//...
private Message msg = new Message();
//...
msg.addPropertyChangeListener(new PropertyChangeListener(){
@Override
public void propertyChange(PropertyChangeEvent evt) {
output.setText((String) evt.getNewValue());
}
});
//...
[/sourcecode]
again using an anonymous inner class to respond to the change. By contrast, here is the Groovy version (where in this case the code is sufficiently succinct that I can include the whole thing):
[sourcecode language="java"]
import groovy.swing.SwingBuilder
import javax.swing.WindowConstants as WC

def model = new Message()

SwingBuilder.build() {
frame(title:'Echo GUI', size:[300,100],
visible: true, defaultCloseOperation:WC.EXIT_ON_CLOSE) {
gridLayout(cols: 2, rows: 0)
label 'Input text: '
input = textField(columns:10,
actionPerformed: { model.text = input.text })
label 'Echo: '
label(text: bind { model.text })
}
}
[/sourcecode]
Once again, this won't work unless you're using Groovy 1.6b2 or above. The bind method has been modified to take a closure as its last argument, and the closure in question refers to the text property of the model, rather than to another widget. Note that now I've gone back to implementing actionListener, because I have to get the text value from the view into the model, so it's not quite as clean as before. That could be changed, but at the moment it seems reasonable to do it that way.

Of course, if we have a model and we have a view, what we need next is a controller. Griffon shows how to do that, but I'll leave it for another post.

The bottom line is that by using Groovy's bind method and @Bindable annotation, constructing a GUI based on a realistic MVC architecture is now viable, and even easy.

Recently I have been building Java and Scala projects with Gant. I think it has been a successful exercise so I am just going to jump on and show you some example buildfiles. The first one is going to be a Java project. This project is obviously toy code but I think if you just download the sample project and start filling in your own code (it's an Eclipse project, Intellij and NetBeans should both import it successfully) you will be happy with how little you have to change the build file.

First have a look at the Gant file itself and then I am going to talk about the things that I think make Gant such a powerful and productive tool. The first thing to point out is the line count, this represents a complete build file for a Java SE project in under 100 lines. That includes the Hello World target I've left in as an echo test. Gant might have a slightly weird syntax if you are unfamiliar with Groovy but it isn't verbose.

Targets and dependencies were in the last post so this time the new thing is using AntBuilder. Any method call that starts with Ant is a invocation of an Ant task. These are nothing but thin wrappers around the normal Ant task (and in fact I usually write them using the Ant Task documentation). Things that are attributes in Ant XML become hash properties in the parameter list. Things that would normally be nested elements are calls to the enclosing builder.

One area where Gant wins big is the way you can mix normal variables, Groovy string interpolation and Ant properties. Declaring the directory paths as Groovy variables near the head of the file allows me to create new paths via interpolation and assign the variable to the properties of an Ant task. Ant XML has properties and macro interpolation but this is both clearer and easier.

I am also using the Gant built-in clean task and in the course of using it, Groovy's operator overloading for lists. I'm not a huge fan of operator overloading but if it's clear enough here then it is great to have a DRY list assignment.

I also like the way that the directories are created in the init task. This kind of closure looping over a list again shows some of the power and conciseness that can be achieved by a language rather than a configuration file. If you don't read Groovy then the each method iterates over the list its attached to and each item resulting from the iteration is stored in the whimsical "it" local variable.

Up and coming

• Neo4J - A graph store - no more ORMappings
• Qi4J - A composite development framework, a new way of writing Java applications, a way of life
• Groovy GRAILS - Excellent for prototyping Java stuff
• Mercurial - When thinking different, why not Version Control as well?
• Swing Appframework, Java6u10 - Propably the next big thing in Rich Internet Applications
• Visualization of graphs - Am looking for a nice, easy API for creating several hierarchical trees that I can drag and manipulate
• Amazon EC2 - Java enabled servers on demand!
• Twitter, Blog, IRC -New (and revisited) ways of communicating intra-project/company
• javaBin, JavaZone - Working with the JavaZone conference for a year was damn fun!
  

Same old

Knowledge Sharing, Wiki, Ideas, Architecture, RFID, Sun Spot, Music, Topic Maps, Maven, Linux, OS X, Continous Integration, Mockito, Testng, REST

Moving away from

Hibernate, Spring, Web, Integration, Grid Frameworks, Web Services, Windows

Current projects

• Music DJ program
• Neo4JDemo
• AnarQi4JDemo - Qi4J
• JavaZone RFID applications

Closed projects

• Web applications on demand - Gigaspaces , web apps
• Kvittr - Grails, posting sms and emailing based on an RSS Feed
• Ultimate Roundtrip - A scaffold for improving development roundtrip for web applications with Maven, embedded Jetty and JWebunit webtests
• Webugger - Embedding a Groovy console efor debugging web and applications with high roundtrip

Ok, lets start with WebSynergy, the very cool thing out there by the colloberation of Sun, Liferay!

Now, our dream development package includes liferay portal + Glassfish server with lots of capabilities i.e. SAW, openESB + Netbeans IDE (I still prefer Eclipse!)+ PortalPack + Groovy DSL/Grails support + Spring + hibernate + MySQL

Ok, if you want to use all these into your company's project, wouldn't it be smart to think of a GEnIUS Build tool to automate getting these sources into one updated package for you to use in development or for production!!

I think that would be incrediably cool to have such tool inhouse while you are developing, I think this calls for a new jcp proposal!

what do you think?

Of course, the growth of Ajax changed a lot of that. I like several of the major Ajax libraries, like prototype, scriptaculous, jQuery, YUI, and so on. One of the interesting trends I've been watching in the industry is whether browser-based GUIs in the future will be written in a Java component library that renders in HTML (like JSF), or written in Java libraries that translate to Ajax/JavaScript (like GWT), or are written using JavaScript components directly (like in YUI or dojo).

Still, I used to write user interfaces in Swing. Several years ago I wrote a Jeopardy-like game that I still use in training classes, where the game board itself is a Swing UI and the clients all have "buzzers" that connect to the game board via RMI. One of my most interesting, and certainly most fragile, projects was about ten years ago when I had to put a Swing GUI on top of a Fortran program (shudder). In case you're wondering, you can't get there from here. You have to go Java to C via JNI, and then C to Fortran (even though they handle arrays differently). It's basically like putting an notch in a beam and telling it to break right here.

But those are stories for another day. Suffice it to say that I feel quite comfortable writing Swing GUIs in raw code (as opposed to graphical drag-and-drop interfaces), complete with inner classes to implement ActionListeners or the like for each button, and so on. I still struggle a bit with the intricacies of GridBagLayout, but I can get pretty far with lots of JPanels and combinations of BorderLayout and FlowLayout.

So when it came time to see what Groovy brought to the table, I thought I was quite prepared. Imagine my surprise to find that, believe it or not, in the last several years the field actually moved on, despite the fact that I almost never get requests for training classes in Swing or related technologies. A lot of people (Andres Almiray, Danno Ferrin, Geertjan, and many more) have spent considerable time and effort applying Groovy to user interfaces and making all kinds of progress.

The culmination of all of this effort is the new, seriously cool, Griffon framework. Griffon promises to bring Grails-like productivity improvements to client-side Java applications. The more I learn about it, the more impressed I am. It's been a bit disheartening, however, to find out how much I still have to learn before I really understand it.

No matter. I like to say that I'm often wrong, but I rarely stay wrong. My next few posts here will be dedicated to principles that I've been learning about user interfaces in Groovy. Hopefully, in addition to providing a nice record for me of what I'm learning, maybe this will help someone else avoid my mistakes.

In this first post, let's get the really well-known stuff out of the way. That's the wonderful elegance of Groovy's groovy.swing.SwingBuilder. SwingBuilder is a great Groovy class, well-described in GinA, that let's you create Swing interfaces almost declaratively.

Here's a trivial Swing application in Java. All it does is take text typed in a text field and echoes it in the text of a label. It's about a simple as Swing applications come.

[sourcecode language="java"]
import java.awt.Container;
import java.awt.GridLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JTextField;
import javax.swing.WindowConstants;

public class EchoGUI extends JFrame {
private JTextField input = new JTextField(20);
private JLabel prompt = new JLabel("Input text: ");
private JLabel echo = new JLabel("Echo: ");
private JLabel output = new JLabel();

private Container cp = this.getContentPane();

public EchoGUI() {
super("Echo GUI");
cp.setLayout(new GridLayout(0,2)); // 2 cols, as many rows as necessary

cp.add(prompt);
cp.add(input);
cp.add(echo);
cp.add(output);

input.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
output.setText(input.getText());
}
});

this.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
setSize(300,100);
setVisible(true);
}

public static void main(String[] args) {
new EchoGUI();
}
}
[/sourcecode]

First of all, this shows me to be an "old school" Swing developer, because I made my application extend JFrame rather than contain a JFrame instance. The trend these days is always to favor composition over inheritance, partly to reduce the coupling and partly to make testing easier (I'll have more to say about testing Swing UIs in a future post). Still, this is the way I learned to do it, and I still fall into old habits, especially for trivial examples.

Second, I'm also arguably violating best practices because my main method instantiates the GUI directly, rather than calling SwingWorker.invokeLater to make sure all user interface updates are done in the Event Dispatch Thread (EDT). You can generally get away with this here, though, because until the GUI is actually rendered it isn't much of a problem. Understanding the details of running on the EDT or not, however, is a big issue for later, too.

Also, I'm still in the habit of adding components to the content pane. I remember vividly when I had to rewrite all my existing Swing apps to add to content pane instead of directly to the frame itself, and I still do that, even though I don't think it's strictly necessary any more.

Finally, I did something here I generally don't do, which is to use an anonymous inner class to handle the action listener for the button. Normally I create an actual (named) inner class for each component that generates events, and add an instance of each to the relevant component. Here, for example, I would normally write an inner class called something like EchoListener, and then add an instance of it to the button. Still, with only one button and an almost trivial inner class, it seemed easier to add it directly, even though arguably this is the ugliest syntax in all of Java, with the possible exception of generics.

Groovy's SwingBuilder cuts this example down to practically nothing.
[sourcecode language="java"]
import groovy.swing.SwingBuilder
import javax.swing.WindowConstants as WC

SwingBuilder.build() {
frame(title:'Echo GUI', size:[300,100],
visible:true, defaultCloseOperation:WC.EXIT_ON_CLOSE) {
gridLayout(rows: 0, cols: 2)
label 'Input text: '
input = textField(columns:10,
actionPerformed: { output.text = input.text })
label 'Echo: '
output = label()
}
}
[/sourcecode]
The SwingBuilder means that I can just write words like frame, label, and textField, and, through the magic of metaprogramming, they are interpreted by the builder as Swing components. The other great part is that Groovy doesn't force you to create an inner class just to hold a method. Closures are perfectly valid objects in their own right, so I can just assign one to the actionPerformed property of the text field, and I'm all set.

That's an amazing savings, and it's just the beginning. The combination of builder methods and closures cuts the amount of code required in a typical Swing GUI by a huge amount.

(I don't know exactly how much, but I'm going to say 80%, because, as you may have heard, 80% of all statistics are made up on the spot.)

For more details, see GinA (Groovy in Action for the uninitiated, and if you are uninitiated and find Groovy cool, get thee hence to a bookstore and buy thee a copy) and the wiki pages at groovy.codehaus.org.

Still, this much I knew when I started my recent adventure. I had no idea about Groovy's cool bind method, which dramatically simplifies the use of PropertyChangeListeners and is a great step along the way to a pure MVC architecture. Then there's the @Bindable annotation that's part of Groovy 1.6 beta 2, which makes it even easier. Then there's the elegant way that Griffon lets you handle scheduling tasks inside or outside the EDT. I also realized that Swing hasn't been idle, too, with the creation of the whole SwingX project and its associated set of components.

It's been a wild ride for me recently, and I don't feel I'm anywhere near finished. My feeling, though, is that Griffon is eventually going to be a very big deal. I know it's making a big difference in how I think about Swing, and I'm looking forward to playing with it more and more.

I have previously had my say about IDE's. They make one's day better by facilitating the development process. They wrap up the tools that individually require considerable skill, turning the whole into a fast and effective point and click experience.

Over the years I have experimented with a range of tools, some now extinct, some withstanding the test of time. I'd like to explore those that make my work effective and get me results.

When it comes to low level work, or just getting something done with no restrictions, I still find that the C programming language is my tool of choice. It does indeed have flaws. But there is (I believe) more Open Source source code out there written in C than any other language. Most importantly my operating systems, my compilers and my Java runtimes are all written in C. Enough said.

When it comes to generic programming work I am torn between two basic choices.

1. The Java programming language, its libraries and platforms (not to mention its developer community) are everywhere. I use Java because when it is appropriate, it is so much better than C, and I can achieve great things with less effort and more certainty.
2. Now I said I was torn between two basic choices. The second is the Dynamic scripting language. I have a few that I like and will use for different reasons. I will use them in place of C and Java if the choice is appropriate. It doesn't matter which ones you choose as long as you choose them for their speed of development so garnered by their more terse expressive qualities. I consider Perl, Python and Groovy to be my candidates.

There are indeed many programming languages out there, but the aforementioned have, to date, either made the most sense or simply given me the most mileage. I hope that you too can find that particular mix which suits your own development end goals. Happy programming :-)

Domainer is currently looking for the best developers in Toronto. What do we mean by the best developers? Well, you should know know your stuff in a profound way. What stuff do you need to know? At a minimum you should know the *nix command line and a how to configure a secure web server. You should also possess a mighty knowledge of mysql and its various quirks. Next you need to know a server side web friendly programming language such as Java, Groovy, PHP, Python or Ruby. Front end language development expertise is also appreciated.

We are doing cool things with new technologies. You will be exposed to an array of technologies such as Groovy, Grails, Java, PHP, jQuery, python, Gradle, Gant, Ant, Subversion, Eclipse, NetBeans, Ubuntu, plus a few that are for you to discover.

The Good
They claim good compensation, but is that just good compensation for those commonly called "web developers" in this city, who are chronically underpaid compared to the rest of the development crowd, or is Domainer really serious about hiring the best, which, IMO, means paying a lot more - probably over $90k in salary alone.  (There may be great people in this city who get paid less, of course, but most of the better people I've worked with make significantly more than this).

If this work were done well, it could be an interesting combination of interesting technology (RSS, mashups, social media, rapid-development web techniques), internal productization and good profit margins.  A lot like agency work, but with much more control - your clients simply want to make money, they don't care what you build their site in, or really, what it does, as long as the output in terms of cash is good.

The tech sounds reasonable for what they're doing, the process, as much as they talk about it, sounds reasonably agile.  The video helps you get an initial feel for what your employers/bosses might be like.

The Bad
If this is done poorly, you're going to be doing the same things over and over to deliver bad content and advertising to the unsuspecting, never get to do a build-out the way you want to, no productization, cheapest-solution-always-wins.  Again, a lot like agency work can be, come to think of it.

There's some information gaps, although the video helps.  How big's the team?  How serious is Domainer about actually delivering value in these sites?  What are some examples of sites they're running?  How much is good compensation?  What're the specifics of their location?

That said, the amount of information in the posting is higher than many. 

YMMV
Your mileage may vary with respect to the 'ethics' of the kind of work that Domainer does.  There is often a kind of opportunistic/exploitative streak in this kind of "leverage a domain name" work, from what I've seen.  I can't speak for Domainer in particular, but these sites often seek to get money through advertising with the minimal required effort -- offering very little value, but profiting from search engine placement and so forth.   You'll have to decide how you feel about that and learn a little more about Domainer's approach.

In Summary
If you want the opportunity to flex your web skills at building sites quickly and cost-effectively in relatively new rapid-development technologies, this might be your thing.  I'd suggest coming to terms on compensation.