Clifton Craig

Good point Guy,

I was thinking in Java. As you pointed out Ruby allows string interpolation making the hello world example more trivial. The Groovy equivalent would be nearly identical replacing #{} with ${}
println "Hello ${world = 'world!'}"

When writing a script you can omit declarations from the variable definitions, when you write a class the declarations are required. You need only declare a variable with the "def" keyword specifying types is optional in "script" files as well as Groovy class definitions.

From a brief look it appears you only need to declare the variable x in your code. That's what the error message is saying.
The following works for me right in GroovyConsole:
public interface MyInterface { void printMessage(); } class Parent implements MyInterface { void printMessage() { println "parent" } } class Child implements MyInterface { void printMessage() { println "child" } } def x = new Parent() x.printMessage() x = new Child() x.printMessage()

incidentally I could omit the def declaration from "x" and still run it in Groovy console because the rules for groovy "scripts" are slightly different than the rule for Groovy class definitions. In your case (in Eclipse) your specifying a Groovy class definition.

Correction,

From my understanding (though the authors can feel free to correct me) you can deploy your Groovy app using only the JRE AND the Groovy jar. All Groovy apps compiled or not have a dependency on the Groovy runtime included as part of all groovy distributed jars. Also, all features will be available whether you pre-compile or not.

Woo-hoo! I win! Thank you JavaRanch! And thanks to the authors and everyone else who participated. Congratulations to the other winners as well!

Ed,

Why not use eachFileRecurs?

Because I was born with slightly enlarged fingers and an arguably reduced cranium. Simply put my fat fingers no more than my small brain. That's a much more elegant approach and thanks for the tip.

Jochen,

I was initially assuming that the closure would not be available for reference inside itself but I felt I'd try it anyhow since Groovy has performed many other amazing and magical feats I got used to "trusting it" to figure out what my intentions were. When MY earlier example ran without error I naively figured that it was resolving the closure from within itself. It's not my fault though. You guys made the language too doggone good! Now people like me are looking for it to read our minds, automagically terminate and unwind inifinte recursive loops, understand swear words, and more! Stop doing such a good job and you won't get any more complaints from me.

Thanks Tug,

I knew it was something stoopid on my part. I completely overlooked how the first example wasn't recursively descending the file system.

Actually I put the redundant toString and new File call in so that I can easily toggle between the two. I started with the first version and added the toString() for the revised version because what i really need in the closure is a File rather than a filename string. BTW, it works when you change it from a closure to a method. My question is why the closure throws an exception on the recursive call?

I know all that. My problem is the second one throws a wierd error Something like:

no Signature of Script28.listAllFiles can be found...

The recursive call doesn't work and I don't understand why when all i did was change the parameter value.

Can somebody tell me why this works:
def listAllFiles = { path -> new File(path).list().each { if(new File(it.toString()).isDirectory()) listAllFiles(it) else println it } } listAllFiles '/home/ccc/jedit/4.2'

while this doesn't?:
def listAllFiles = { path -> new File(path).listFiles().each { if(new File(it.toString()).isDirectory()) listAllFiles(it) else println it } } listAllFiles '/home/ccc/jedit/4.2'

Gregg,

no offense taken. I'm sure you have written or seen code that makes Swing development less painful. Groovy offers it's own unique approach that's built in natively. The advantage of Groovy, as I believe you are beginning to see, is that these as well as many other features come bundled in the package. You get your closures, your builders, you meta-programming facilities, your typeless syntax, your Java API, your burgers and your fries all in a one stop shop.

Hello,

1. is there any sample show how groovy used on top of java ?

2. groovy mainly use for web application ? is groovy something like jsp ?

3. how stable of groovy ?

4. is there any good reference site for groovy ?

5. is groovy tend to improve java application performance?

1. Groovy pretty much "is" Java with an augmented and relaxed syntax and a different compiler. So you don't have to run "on top of" anything. Most anything you can code in Java you can code in Groovy. You would need to groovyc instead of javac when you want to compile. (Noting that compilation is optional.) Here's an example Groovy script:
import java.io.File println "Are we probably running on windows? " + new File("C:\\Windows").exists()
You can run in interpreted mode and use the BeanScriptingFramework approach towards embedding. That would give you Groovy "on top of" Java.
2. Groovy is a general purpose programming language. As such it can be used for templating (which it has lots of wild support for), web apps (see GSP or Grails), desktop GUIs (using something like SwingBuilder), or anything you need.
3. Groovy just released it's 1st released candidate about a week ago. Prior versions to that have showed problems mostly with special use cases. I'd say it's pretty stable but that's entirely subjective.
4. See the docs on its home page: http://groovy.codehaus.org/Documentation
5. Groovy is inteded to improve Java's usability. In other words it's more programmer friendly making programs easier to write and easier to maintain. Goals like this are always in opposition to performance. Consider your task. If you need nose-bleed critically high performance (which many modern apps really do not need) then you would use a lower level programming language like C. That said Groovy's performance, as far as I can tell, has been acceptable. I would say in most typical uses performance of the language would not be a concern.

Never had cak before huh? You've lived a sheltered life! Since Groovy is the next best thing to cak I'd suggest you try it too.

Also conceding that I tend to want to know if my code is going to break before I run it, which proves difficult with dynamic languages.

You should know that can be just as difficult with traditional compiled languages as well. That's why there are things such as Unit testing and TDD that go along way towards ensuring you write the right code the first time around. (You should check out the unit testing support built natively into Groovy as well!) Type checking imposed by the compiler is a dagger baked in a cake. (Or a dagger baked in a cak!) It's one of those risk vs. reward things. (I did spell that correctly right?) What I'm saying is consider the tradeoffs before praising your compiler.

Gregg,

SwingBuilder buys you a hierachial-like API for constructing GUIs. Used along with other Groovy features like optional Map bracket syntax what you get is a lot more visually appealing than regular Java Swing code. Here's a brief example:
import java.awt.BorderLayout def swing = new groovy.swing.SwingBuilder() swing.frame(title:'MY GUI',location:[100,100],size:[800,400], defaultCloseOperation:javax.swing.WindowConstants.HIDE_ON_CLOSE) { menuBar { menu(text:'File') { menuItem { action(name:'Exit', closure:{System.exit(0)}) } } menu(text:'Help') { menuItem { action(name:'About', closure:{swing.optionPane(message:'My GUI Version 1.0') .createDialog(frame, 'About').show()}) } } } panel(layout:new BorderLayout()) { textField() } }.show()

[ December 12, 2006: Message edited by: Clifton Craig ]
[ December 12, 2006: Message edited by: Clifton Craig ]

Gregg,

My question to this is, then why use Groovy? If you are going to compile to bytecode anyway, and jar them up, why not just stick with Java.

Because Groovy has advantages other than being a scripting language. Groovy is a dynamic language. That is it adds dynamic features to your programming experience. People typically choose a scripting language not just because it doesn't require compilation but because of the features the language brings. The lack of a compile step is most often just a welcome side effect just like regreesion tests are a side effect of using TDD. Contrast the capabilities of Groovy with that of Java. To get a good picture of what I'm talking about do a Google search on "Ruby vs. Java" and do a mental scan and replace of the word Ruby with the word Groovy. All of the arguments you'll find apply to Groovy as well. Groovy has the advantage of being able to be compiled and deployed right along side of Java.

In short Groovy has all the advantages of Ruby without Ruby's main disadvantages. (runtime interpretation, Java impedance mismatch.) It's a cak-and-eat-it-too deal.