The main advantage is simply being able to write in Groovy. If you can write a component more quickly using less code that is more understandable, that's a win. Groovy development doesn't require a compile step, which might make your development faster. Basically, if you prefer Groovy, for whatever reason, Seam is there for you. I think being able to write a facelets template that talks directly to a groovy component is pretty neat thing, but if you don't already have a need/desire to use Groovy, stick with Java. There's no obligation to make use of it.

We don't provide any direct integration with other Groovy technologies like GSP, but we'd welcome any Groovy users out there to try it out and report back. We're rather eager to make Seam more groovy.

I have been writing Seam app using only groovy.
It works nicely (although I had to upgrade to groovy-1.1-beta-3).

Biggest issue is JPA entities there groovy works like miracle. Since groovy generates getters and setters for variable without scope.

So jpa entity written in groovy looks like this:

@Entity
class MyEntity implements Serializable {
@Id
Integer id
String value_field
}

Today the main reason to use Groovy in Seam is the language features: closure, duck typing, list, map, properties etc etc. So essentially, code conciseness.
The hot deployment can actually be done with regular classes (provided that you compile them).

In the near future, we plan to do some things related to GString and Seam injection. Depending on how people are interested, something like GORM for DAOs might be on the target too.

About hot deployment:
When I use java to write service component, and modify the java source code, hot deployment take effect. But when I use groovy to write service component,the hot deployment effect disappear.

Can anyone help me?

The above hot deployment occurs only in Glassfish v2ur1, in Tomcat 6.0.14, it is ok?

The above hot deployment problem occurs only in Glassfish v2ur1, in Tomcat 6.0.14, it is ok!