According to James Strachan, the Groovy team have been making good progress lately. They've been working on a new JSR parser based on Antlr and they've just released 1.0-BETA-10 which includes an EA release of the new JSR parser as well as the Classic Groovy parser. In a couple of weeks the first beta of the JSR version of Groovy will be out which should provide a fairly solid base going forward.

Read Groovy making good progress on James Strachan's blog.

Scripting languages are mainly used for system level scripts, like startup scripts for Weblogic or Tomcat, cronjobs or even Clearcase triggers. For all this shell or perl scripts are used and you cannot replace them with Java or Groovy either, because Groovy is a Java Programm and suffers in the same way as Java with the VM's way too high startup time.
What I'd need were a not a new scripting language, but an interpreter with Java's syntax and libraries with Perl's startup time so I could replace Perl scripts with Java Scripts (not JavaScript !). I don't have any need for a new syntax for a Java program.

Juergen

Scripting languages are mainly used for system level scripts,...

They said same thing about p-code!

The future langage will be loosley typed, we should learn from the sucess of deployed p-langs. (AFIAK, Google uses Python)

Anyone the codes action script or p-langs will get it. And... you can "compile" Grooby to p-code if you want.

Something like Grooby will be big. I hope that they are able to compleate (maybe they won't, so someone else needs to step in - Ruby?)

.V

http://phplens.com/phpeverywhere/?q=node/view/157

For me this whole Groovy project just looks like James' hobby project. He wanted to learn how to write a new scripting-programming language.

Have you tried it already or you are just a blog reader??

Please read some of the documentation and try it. For me (and many others) Groovy is one of the most exciting things that happened to Java for a long time (not only the language itself, but Groovlets, Groovy SQL, etc, etc, etc!). I already use it in many areas (for example, all my Unit Tests are already coded with groovy).

I'm sure that all the groovy team will appreciate your comments on how to design better the language, so jump to the project tracker and insert your suggestions.

I really thank James, Guillaume and others that do such a great work!

Pedro Costa

I for one have tried it. The problem with groovy is more about "trust" than anything else. Can I trust that in 6 months/1 year groovy will still be around?

Groovy is JSR 241 and if you look at the roadmap (http://groovy.codehaus.org/Roadmap) you will see that its being followed. Look at the title of this article!

But, speaking about trust and the future... Can we trust that in 10 years Java will be around? IBM or Oracle will buy Sun? (if not, I really have fear for Java) .NET will have 90% of the market?

I'm a big fan of scripting languages, but not for every job. I find them particulary usefull for fast prototyping ideas and algorithms and for many other things like Unit Testing (try it, you will never write again tests in other language). For this, Groovy gives me the possibility of calling all my other java code and libraries (like Jython did, but I really prefer Groovy).

I find Groovy so groovy that I really trust it will be a success, but even if not, groovy output is java bytecode, so its not a dead end.

Pedro Costa

hi Pedro,

interesting idea (using groovy for unit testing)

would you mind posting some examples?

cheers
J.

hi Pedro,interesting idea (using groovy for unit testing)would you mind posting some examples?cheersJ.

Sure. But its faster to point you to:

http://www-128.ibm.com/developerworks/java/library/j-pg11094/

Take a look at all the "Practically Groovy" articles at DeveloperWorks! You will find them interesting and usefull!

http://www-106.ibm.com/developerworks/views/java/articles.jsp? sort_order=desc&expand=&sort_by=Date&show_abstract=true&view_by= Search&search_by=practically%20groovy


Hope its usefull
cheers

Pedro Costa

thanks!
 J.

Disclaimer: I like/need a Javaish scripting language.
The following are some thoughts on the merits of Groovy
as a Scripting language and its current state.

When I had a first look at Groovy some months ago it
looked to me like a Java version of Perl :-(

The syntax was quite difficult with "dialects" for each and
everyones pet domain (XML, SQL). The parser was hand crafted
in a strange mix of bottom-up and top-down parsing. I
had considered to write an Eclipse plugin (with code
completion in mind) but the syntax/parser which could
not be retrofitted with a reasonable effort made me
step back.

Back then even the method dispatching (which seems to me
one of the central pieces for a sripting language that
wants to _extend_ Java) was shaky and far from final.

I am very glad to hear that they try to move to a parsing
tool like ANTLR which makes the grammar more explicit and
visible.

I still fear some kind featuritis especially w.r.t.
to special syntax for domains like SQL , XML and the like.
I would like to see a stable core emerge with some
well defined concepts (e.g. closures, method invocation)
and leave the special stuff for some later release when the
core has proved to be valuable.

Victor

Some people asked why we need scripting at all. Since with just Java we have homogenous environment and do not need to learn a new language.

I think I may have a valid example:
When (super)users need to implement/configure business logic/rules.

I used to work with a company developing laboratory information systems for healcare. They had 1000's of rules like, if a test of this type gives a result below that value, then automatically order these tests too.

As a developer may not want to configure/implement these things that change frequently and I sure do not want users hacking away in java application code.

Talented SW-developers are rare, let them focus on core design etc. and push no-good-hacks into a scripting language that execute in a more controlled environment.

Regards
Jan Hornbøll Hansen

Some people asked why we need scripting at all. Since with just Java we have homogenous environment and do not need to learn a new language.I think I may have a valid example:When (super)users need to implement/configure business logic/rules. I used to work with a company developing laboratory information systems for healcare. They had 1000's of rules like, if a test of this type gives a result below that value, then automatically order these tests too.As a developer may not want to configure/implement these things that change frequently and I sure do not want users hacking away in java application code.Talented SW-developers are rare, let them focus on core design etc. and push no-good-hacks into a scripting language that execute in a more controlled environment.RegardsJan Hornbøll Hansen

Good point about externalizing rules, however, would you trust someone who cannot handle simple business logic in java to handle simple business logic in a scripting language that looks like java?

Why not get an rules engine like Ilog or craft something that keeps the users out of the programming business?

... would you trust someone who cannot handle simple business logic in java to handle simple business logic in a scripting language that looks like java?

Yes

Why not get an rules engine like Ilog or craft something that keeps the users out of the programming business?

I am not familiar with these products. I was just trying to give an example why scripting can be usefull. I know games industry also use script-like languages. They typically have ppl working on game engine in C++, content developers use some kind of scripting.

I kinda like the separation because it shields engine developers from poluting their highly optimized and probably well organized code, with code from people who may be less talented.

I would love if my company worked along the same lines, not everyone have the nessesary skills to produce fairly decent Java code. People who shouldn't be doing Java could still be usefull in some way using scripting languages where they would probably create less havoc.

Regards
Jan Hornbøll Hansen

... would you trust someone who cannot handle simple business logic in java to handle simple business logic in a scripting language that looks like java?

Yes

Why not get an rules engine like Ilog or craft something that keeps the users out of the programming business?

I am not familiar with these products. I was just trying to give an example why scripting can be usefull. I know games industry also use script-like languages. They typically have ppl working on game engine in C++, content developers use some kind of scripting.I kinda like the separation because it shields engine developers from poluting their highly optimized and probably well organized code, with code from people who may be less talented.I would love if my company worked along the same lines, not everyone have the nessesary skills to produce fairly decent Java code. People who shouldn't be doing Java could still be usefull in some way using scripting languages where they would probably create less havoc.RegardsJan Hornbøll Hansen

Well, different strokes, I guess. Like you, I've dealt with my share of users, and they were not people who were able to handle programming tasks. A scripting language was out of the question. I don't believe someome who is incapable of modifying a simple block of java code is capable of modifying a java-like scripting language.

However, they can handle a GUI with a set of options and construct rules, similar to an email filter.

It isn't an accident that so many email filters don't use scripting as their main method of allow users to modify filter rules.

I tried it as well. Though I liked it, I found it (1.0 beta7, as upgrading gave conflicts with Hibernate) not suitable for production yet. I switched to PNuts, which works really great, has good documentation and a generally nice API.

I whish the Groovy guys luck, as I think it is a good thing to have a standard scripting extension for Java. Unfortunately, Codehaus does not have a very good track record at actually finishing projects...

I tried it as well. Though I liked it, I found it (1.0 beta7, as upgrading gave conflicts with Hibernate) not suitable for production yet.

I think that the suffix beta7 implies that its not meant to be ready for production.
Try beta10! A lot better!

Unfortunately, Codehaus does not have a very good track record at actually finishing projects...

As an ActiveMQ, AspectWerkz and Drools user, I dont agree...
We can also mention OpenEJB that turned into Geronimo EJB container and PicoContainer thats being used in many places (I myself use Spring).
I bet you will find a higher number of dead projects in sourceforge. Its the natural selection working... only the strongest survive, the others die...

Pedro Costa

I think that the suffix beta7 implies that its not meant to be ready for production.
Try beta10! A lot better!

At what point does a beta product become production ready? beta8, beta9 or beta10?

:)

At what point does a beta product become production ready? beta8, beta9 or beta10?:)

Like I said, the suffix beta implies that its not meant to be ready for production. He was telling he had problems with beta7 and I adviced him to to try beta10. Never said that beta10 was ready. You can read the roadmap to see when a 1.0 version is expected.

Meanwhile, I must say that I've been using Groovy with great success for several months. I would not bet on it if I was coding something to be used in a nuclear submarine, but for more mundane tasks its allright, so far.

Pedro Costa

(for example, all my Unit Tests are already coded with groovy)

Why ?

I write my Junit tests in Java.

- I get compile time type safety.
- I don't have to learn a new language.
- I can use the tools I already have to hand, such as the debugger.
- I'm productive as I've used java for years.

I can't see one tangible benefit for using a scripting language to write unit tests, that would make me want to lose the above.

Ian Purton
End Of Year Rock Lists

- I don't have to learn a new language.
- I can use the tools I already have to hand, such as the debugger.
- I'm productive as I've used java for years.

Take a closer look at the articles that I mentioned.
Consider Groovy (as other script languages) as another tool on your toolbox. Use it when you think It will be usefull.

I think that with time I will code in Groovy more and more, (like doing my business logic, etc..), but even If will not, It still be a great tool for many things (Prototyping, Unit Testing, Embedded Script Engine, General Scripting, Configuration, etc, etc, etc..).

<joke>
I think that the problem with your aproach is well described in Abraham Maslow maxim: -

"If the only tool you have is a hammer, you will see every problem as a nail."

</joke>

Pedro Costa

Take a closer look at the articles that I mentioned.

I read the articles, still haven't found a good reason to add yet another language to my repetoire.

I think that with time I will code in Groovy more and more, (like doing my business logic, etc..),

Why ?

<joke>

"If you have too many hammers then someone else will bash your nail in whilst your decided which one to use."

</joke>

- I don't have to learn a new language.- I can use the tools I already have to hand, such as the debugger.- I'm productive as I've used java for years.

Take a closer look at the articles that I mentioned.Consider Groovy (as other script languages) as another tool on your toolbox. Use it when you think It will be usefull.I think that with time I will code in Groovy more and more, (like doing my business logic, etc..), but even If will not, It still be a great tool for many things (Prototyping, Unit Testing, Embedded Script Engine, General Scripting, Configuration, etc, etc, etc..).<joke>I think that the problem with your aproach is well described in Abraham Maslow maxim: -"If the only tool you have is a hammer, you will see every problem as a nail."</joke>Pedro Costa

I don't think that that is a appropriate analogy. A hammer is good for two things, putting nails in and pulling nails out.

Java is a tool that is much more versatile and as such can be used in many more contexts, unlike a hammer.

Therefore, there has to be, reasonable, a real benefit for using something like Groovy. I've gone from C->C++->Java, so I don't have a problem with picking up a new language, but I've yet to have a good reason, IMO, to deal with any of the scripting languages.

For now, I don't find them to be particularly compelling solutions.

For now, I don't find them to be particularly compelling solutions.

Well said.

- I don't have to learn a new language.- I can use the tools I already have to hand, such as the debugger.- I'm productive as I've used java for years.

Take a closer look at the articles that I mentioned.Consider Groovy (as other script languages) as another tool on your toolbox. Use it when you think It will be usefull.I think that with time I will code in Groovy more and more, (like doing my business logic, etc..), but even If will not, It still be a great tool for many things (Prototyping, Unit Testing, Embedded Script Engine, General Scripting, Configuration, etc, etc, etc..).<joke>I think that the problem with your aproach is well described in Abraham Maslow maxim: -"If the only tool you have is a hammer, you will see every problem as a nail."</joke>Pedro Costa

The hammer metaphore doesn't fit here. Why do I need to come up with a whole brand-new script syntax just to run JUnit test cases? My unit tests are testing Java code, so why should they be written in any language other than Java? What is the benefit? I read the developerWorks article and basically it says:

• Groovy script tests are shorter than the corresponding Java JUnit tests, basically because you don't need type declarations or semi-colons at the end of lines.
• Groovy has some new Assertions, which are more convenient than the existing JUnit assertions. Of course, you could also just create new assertions in plain ole Java by extending JUnit.
• The rest of the artical goes on to tell you how you can do things like invoke your groovy unit tests from Eclipse, or Ant, or Maven, which you can already do with JUnit tests, because Eclipse and Ant and Maven all have built in support for them...

Of course the article does not mention any of the downsides of using Groovy to create unit tests.

• You have to learn Groovy
• People who maintain my code two years from now have to learn Groovy.
• If I have a syntactical error in my Junit test case, my Java IDE tells me before I compile... in fact, it highlights the error and sometimes even offers me some suggestions on how to fix the error. Groovy doesn't have any of that

The artical also doesn't mention that there are a lot of tools that will generate the skeleton of your use cases for you in Java anyway... I'm not sure if there are code-generation tools for Groovy yet.

Why do I need to come up with a whole brand-new script syntax just to run JUnit test cases

I never said you need! If you dont find interest in scripting languages and Groovy in particular; if concepts like closures dont interest you, it would be stupid to learn Groovy just to do Unit Testing.

The idea is to look at Groovy as a general tool. Thats my opinion, and as you can see I'm very happy with it.

Pedro Costa

I built a homgrown app to test my Java code using Groovy
+ Spring + Maven ( project.xml to define dependevcies)
Here is snippet from my applicationContext-testcases.XML you may find interesting:

<bean id="testsRunnerBean" class="org.jxray.preflightchecks.spring.TestRunnerBean">
<!--
TestRunnerBean beans executes ecah of the following test cases
-->
<property name="testCases">
                    <list>
                    <ref bean="case1"/>

                    </list>
                </property>
</bean>
        
        
        
        <bean id="case1" class="org.jxray.preflightchecks.spring.TestCaseImplBean">
            <property name="testName"><value>Test Framework DAO: group persmission with 0 param</value></property>
            <property name="testDescription"><value>Test getAllUserPermissionsInheritedFromGroups </value></property>
            <property name="targetBean"><ref bean="frameworkDAO"/></property>
<!--
Target bean is the being whose methd is being tested.
It is defined in the normal Spring applicationContext file
-->

                       
            
            <property name="bindedParametersMap">
                <map>
                    <entry key="permission"><ref bean="createCustPermision"/></entry>
                    <entry key="targetBean"><ref bean="frameworkDAO"/></entry>
                </map>
            </property>
            
            <property name="groovyScript">

<!--
The TestRunnerBean will instantiate a groovy shell and create the bindings from the 'bindedParametersMap'
-->
             <value>
             List list=targetBean.getAllUserPermissionsInheritedFromGroups("ceasuser44",permission );
             if( (list==null)|| (list.size()==0)){
             System.out.println("Error: unexpected results");
             }
             else{
             System.out.println("test okey dokey");
            
             }
             </value>
            </property>
        </bean>

Ok so this is not as polished as you may want. But it does help me test all my DAO classes. I can set up configuration info in my Spring applicationContext files and the DAO gets initialized properly by Spring. The TestRunner bean interprets the test cases , creates Groovy bindings and Groovy shell . The Groovy shell executes the script.

I can keep on adding test cases ,vary the data and expand test coverage to add new methods to test or test the same methods with different data set-- all without recompiling or extra coding.

(yet to do : integrate with junit reporting)

Be a nice guy, will you ;-)
Any beta is a beta and not for production, regardless of numbers and as long as the developers think so.
Sooner or later ther will be a production version.
Or maybe it wont.
/Petit

Groovy for unit testing. On the groovy website there is a page dedicated this idea but the example, sadly, doesn't use show the power of scripting language.

It would be really nice if one could write an article about groovy makes life easier for a java developer. The article should illustrate the traditional way of doing things and then the groovy way.

- Neeraj

It would be really nice if one could write an article about groovy makes life easier for a java developer.

I'm sure that there are plenty of others, but (like I said above) take a look at the "Practically Groovy" articles at developerWorks:

http://www-106.ibm.com/developerworks/views/java/articles.jsp ?sort_order=desc&expand=&sort_by=Date&show_abstract=true&view_by=Search& search_by=practically%20groovy


Pedro Costa

Groovy is great, fast, reliable and the only real future standard for scripts.
I used BeanShell for two years, I liked it, but I never compare FIAT to Ferrari.....

As Java gets less and less productive compared to the state of the art, it's becoming clear that something else will emerge. Having an affinity to Java, and running in the JVM,is a big time plus.

As Java gets less and less productive compared to the state of the art,

My experience is Java is becoming more productive as the years roll on and the tools/libraries get better. If you're implying Groovy is state of the art and is more productive than Java then I'd be interested in hearing why you think that is the case.

If you're implying Groovy is state of the art and is more productive than Java then I'd be interested in hearing why you think that is the case.

I'm not saying its state of the art. Just saying that I really like it. Regarding the productivity, lets look at some code:

JDBC programming in normal Java

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
public class JDBCExample1 {
  public static void main(String[] args) {
    Connection con = null;
    Statement stmt = null;
    ResultSet rs = null;
    try{
      Class.forName("org.gjt.mm.mysql.Driver");
      con = DriverManager.getConnection("jdbc:mysql://localhost:3306/words",
           "words", "words");
      stmt = con.createStatement();
      rs = stmt.executeQuery("select * from word");
      while (rs.next()) {
        System.out.println("word id: " + rs.getLong(1) +
            " spelling: " + rs.getString(2) +
            " part of speech: " + rs.getString(3));
      }
    }catch(SQLException e){
      e.printStackTrace();
    }catch(ClassNotFoundException e){
      e.printStackTrace();
    }finally{
      try{rs.close();}catch(Exception e){}
      try{stmt.close();}catch(Exception e){}
      try{con.close();}catch(Exception e){}
   }
  }
}

Welcome to GroovySql!

import groovy.sql.Sql
class GroovySqlExample1{
  static void main(args) {
    sql = Sql.newInstance("jdbc:mysql://localhost:3306/words", "words",
           "words", "org.gjt.mm.mysql.Driver")
    sql.eachRow("select * from word"){ row |
       println row.word_id + " " + row.spelling + " " + row.part_of_speech
    }
  }
}

For example, for fast prototyping, imho, no comparison can be done!
But thats my opinion... The right tool in the right hand.
I must say that I'm a big fan of scripting languages, long before Groovy. Java is my main dev language but I've also used Python with a lot of productivity and success.

Pedro Costa

If you're implying Groovy is state of the art and is more productive than Java then I'd be interested in hearing why you think that is the case.

I'm not saying its state of the art. Just saying that I really like it. Regarding the productivity, lets look at some code:JDBC programming in normal Java

JDBC programming in normal Java

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
public class JDBCExample1 {
  public static void main(String[] args) {
    Connection con = null;
    Statement stmt = null;
    ResultSet rs = null;
    try{
      Class.forName("org.gjt.mm.mysql.Driver");
      con = DriverManager.getConnection("jdbc:mysql://localhost:3306/words",
           "words", "words");
      stmt = con.createStatement();
      rs = stmt.executeQuery("select * from word");
      while (rs.next()) {
        System.out.println("word id: " + rs.getLong(1) +
            " spelling: " + rs.getString(2) +
            " part of speech: " + rs.getString(3));
      }
    }catch(SQLException e){
      e.printStackTrace();
    }catch(ClassNotFoundException e){
      e.printStackTrace();
    }finally{
      try{rs.close();}catch(Exception e){}
      try{stmt.close();}catch(Exception e){}
      try{con.close();}catch(Exception e){}
   }
  }
}

Welcome to GroovySql!

import groovy.sql.Sql
class GroovySqlExample1{
  static void main(args) {
    sql = Sql.newInstance("jdbc:mysql://localhost:3306/words", "words",
           "words", "org.gjt.mm.mysql.Driver")
    sql.eachRow("select * from word"){ row |
       println row.word_id + " " + row.spelling + " " + row.part_of_speech
    }
  }
}

For example, for fast prototyping, imho, no comparison can be done!But thats my opinion... The right tool in the right hand.I must say that I'm a big fan of scripting languages, long before Groovy. Java is my main dev language but I've also used Python with a lot of productivity and success. Pedro Costa

???????

Why do people insist on show the antagonist in the most expressive, most verbose way possible compared to their protagonist's most concise verbage?

I'm not even going to waste time and bore people by showing how you can truncate that program down.

If that is your "normal" Java, no wonder you like Groovy. But I can say in all honesty, if someone came up to me using this as a selling point of Groovy, I'll laugh them out the door.

No offense.

If that is your "normal" Java, no wonder you like Groovy

I copyed it from one of the articles, but, I really would like to see your "normal" code to do the same. Please enlight me! I'm sure you will not bore anyone. We will learn!

But I can say in all honesty, if someone came up to me using this as a selling point of Groovy, I'll laugh them out the door.

No offense.

I dont get offended for so little. The example shows the use of a closure, that its one (of many) really cool things of Groovy.

I'm just quietly giving my opinion in a friendly way. If its to much for you, I apologize and end the discussion here.

cheers

Pedro Costa

If its to much for you, I apologize and end the discussion here.cheersPedro Costa

Your comments are appreciated even if we don't agree, I've had a bee in my bonnet about issues such as this for a while and it's nice to bounce a few ideas back and to.

regards

Ian.

Your comments are appreciated even if we don't agree, I've had a bee in my bonnet about issues such as this for a while and it's nice to bounce a few ideas back and to.regardsIan.

Thanks Ian,

I we all agree on this subject the thread would not have half the comments. I like you think that friendly discussion between persons with different opinions is very interesting and educative process. We just have to keep our minds open.

cheers

Pedro

I really would like to see your "normal" code to do the same.
cheersPedro Costa

This works for me for prototyoing :)

import java.sql.*;
public class JDBCExample1 {
  public static void main(String[] args) throws Exception{
      Class.forName("org.gjt.mm.mysql.Driver");
      Connection con = DriverManager.getConnection("jdbc:mysql://localhost:3306/words",
              "words", "words");
      ResultSet rs = con.createStatement().executeQuery("select * from word");
      while (rs.next()) {
        System.out.println("word id: " + rs.getLong(1) +
            " spelling: " + rs.getString(2) +
            " part of speech: " + rs.getString(3));
      }
  }
}

I really would like to see your "normal" code to do the same. cheersPedro Costa

This works for me for prototyoing :)

import java.sql.*;
public class JDBCExample1 {
  public static void main(String[] args) throws Exception{
      Class.forName("org.gjt.mm.mysql.Driver");
      Connection con = DriverManager.getConnection("jdbc:mysql://localhost:3306/words",
              "words", "words");
      ResultSet rs = con.createStatement().executeQuery("select * from word");
      while (rs.next()) {
        System.out.println("word id: " + rs.getLong(1) +
            " spelling: " + rs.getString(2) +
            " part of speech: " + rs.getString(3));
      }
  }
}

Sure it does. Like I said, I just copied the example from an article.

I was not trying (like someone said) to show the difference in the size of the code. It was the groovy style of coding that I was trying (maybe failing) to show.
I was trying to show the power of Groovy Iterators and Closures and the power of some Groovy extensions like GroovySQL and Groovlets.

Another simpler example (again from the articles):

Java Code

import java.util.ArrayList;
import java.util.Collection;
import java.util.Iterator;
public class JavaIteratorExample {
  public static void main(String[] args) {
     Collection coll = new ArrayList();
     coll.add("JMS");
     coll.add("EJB");
     coll.add("JMX");
     for(Iterator iter = coll.iterator(); iter.hasNext();){
        System.out.println(iter.next());
     }
  }
}

Groovy code

class IteratorExample1{
   static void main(args) {
     coll = ["JMS", "EJB", "JMX"]
     coll.each{ item | println item }
   }
}

This is a very simple example. You would be surprised on how powerfull this can be.

For more simple but interesting examples and for a small introduction to Groovy, take a look at the "Feeling Groovy" article at DeveloperWorks:

http://www-128.ibm.com/developerworks/java/library/j-alj08034.html

Cheers

Pedro Costa

class IteratorExample1{
   static void main(args) {
     coll = ["JMS", "EJB", "JMX"]
     coll.each{ item | println item }
   }
}

You have to find better examples... :D

public class JavaIteratorExample {
    public static void main(String[] args) {
        String[] coll = {"JMS", "EJB", "JMX"};
        for (String item : coll) {System.out.println(item);}
    }
}

class IteratorExample1{
   static void main(args) {
     coll = ["JMS", "EJB", "JMX"]
     coll.each{ item | println item }
   }
}

You have to find better examples... :D

public class JavaIteratorExample {
    public static void main(String[] args) {
        String[] coll = {"JMS", "EJB", "JMX"};
        for (String item : coll) {System.out.println(item);}
    }
}

You are again worried about the size of the code!!
This is not a competition to choose who is able to do much with less code (Perl guys would win that by a large margin).

Its the concept of closure that I was trying to show, so I choosed very simple examples. I see I'm failing and I dont want to waste more space here with code.
Please take a look at the "Feeling Groovy" article for a good introduction and to see some simple but interesting examples. After, if you want, I can show you some big and complicated examples:

http://www-128.ibm.com/developerworks/java/library/j-alj08034.html

There you will read this: -

"Closures are first class objects that are similar to anonymous inner classes found in the Java language. Both closures and anonymous inner classes are executable blocks of code; however there are some subtle differences between the two. State is automatically passed in and out of closures. Closures can have names. They can be reused. And, most important and true to Groovy, closures are infinitely more flexible than anonymous inner classes!"

Sorry for my examples.. :)

Cheers...

Pedro Costa

Sorry for my examples.. :)

That was my point, your examples don't demonstrate real power of closures :-(
Unfortunately creators of Groovy decided not to introduce continuations and as result closures lost huge part of their power...

That was my point, your examples don't demonstrate real power of closures :-(Unfortunately creators of Groovy decided not to introduce continuations and as result closures lost huge part of their power...

Yes, I agree. But I think that it was because of this:

From "The Ruby Language FAQ" (http://rootr.net/rubyfaq-11.html)

Ruby's continuations allow you to create an object representing a place in a Ruby program, and then return to that place at any time (even if it has apparently gone out of scope). Continuations can be used to implement complex control structures, but are typically more useful as ways of confusing people.

I think that the part: "are typically more useful as ways of confusing people" weighted on the decision... :)

Pedro Costa

I think that the part: "are typically more useful as ways of confusing people" weighted on the decision... :)Pedro Costa

What is more important is that continuations allow to decouple code execution flow from threads. So, you can transparently (well... using continuations :) ) transfer execution state between multiple threads and even processes (or JVMs) in case of "serializable" continuations.

I'm not saying that Groovy is the end-all. It has some real problems, and some inconsistencies that will get in the way. I do believe that

1) Type safety is an artificial safety net. (Credit to Dave Thomas, James Duncan Davidson for coining the phrase.) Most of the objects in any given java application today are in collections. You need to up cast from object when you pull them out of a collection. You either solve the problem with a whole lot of ugly syntax (generics) or you learn to live with it. Dynamic duck typing is more productive, for the most part.

2) Code blocks and closures make many solutions more elegant. We've quit coding in that style because doing it with anonymous inner classes sucks. It's painful to write and painful to read. In Groovy, Ruby, Smalltalk it is second nature.

3) Size does matter. For the most part, you want to do more work with each character, without sacrificing readability. That's what increasing abstraction is all about. In this case, if you could hide the iterator, or the type casts, or the exception processing (at least, until you really need to deal with it), why wouldn't you?

Several process improvements, like better unit testing, make some of these feasible...like dynamic typing. I don't think that Java is as productive as it needs to be. That's driving things like lightweight containers and transparent persistence and AOP. These things are pushing Java in some pretty unnatural ways...but it hasn't broken yet. It is, however, straining at the load.

Make no mistake. Scripting languages are important, and will begin to be more so. I think that Ruby on Rails is developing some real momentum...not for all applications, but for a relatively large subset of the applications that we code in Java. But Groovy has one very important advantage over Ruby: the JVM.

Why not request java be extended to include closures?

I am very interested in Groovy but keep running into the problem of maintenance. The code I write needs to be maintained by other developers. Even if Groovy is great, i would need to train the other engineers in it and get long term company buy in.

I favor simple, obvious syntax over clever constructs. This is why I agree inner classes are not a great solution, and closures are easier to read.

(i suspect some one already has?)

- Matt

You have to find better examples... :D

Thanks Serguei!
I never understood what all this "groovy" squeal is about.

- 1-st scripting language in java ? No. There's Jython, Beanshell, and many others long before Groovy.

- best scripting language for java ? No. For my taste Jython wins hands down.

- most powerfull scripting language ? No, again Python/Jython is much more powerfull languages than Groovy.

- most consise scripting language ? No, again looses to Jython.

Groovy is much more politic hype than anything special/good/powerfull.

It is a mediocre scripting language that cannot compete with Python or Ruby.

I'm sorry for java community that such a mediocrity was chosen as a JSR. :(

except the political backing of Sun, and thus momentum. The most important step forward in Groovy was a political one. Sun has a whole lot invested in the Java brand, and it took real competition and foresight to back another language.

I honestly don't think this had anything to do with Sun or with politics. The groovy team decided to submit their language for inclusion in the JCP and had it accepted. The people behind Jruby and Jython (as far as I'm aware) did not. Since it has, undeniably, contributed to the momentum around Groovy I don't know why they don’t get on with it and submit them now.

except the political backing of Sun, and thus momentum. The most important step forward in Groovy was a political one. Sun has a whole lot invested in the Java brand, and it took real competition and foresight to back another language.

BEA have included support for Jython in the upcoming version of WebLogic Server (WebLogic Scripting Tool) so if you are worried about commitment from commercial players - there you have it.

Also Gosling said that Sun won't favour any of the scripting languages so you won't get any help there....

Don't understand this argument.

----- Trond

If that is your "normal" Java, no wonder you like Groovy

I copyed it from one of the articles, but, I really would like to see your "normal" code to do the same. Please enlight me! I'm sure you will not bore anyone. We will learn!

But I can say in all honesty, if someone came up to me using this as a selling point of Groovy, I'll laugh them out the door.No offense.

I dont get offended for so little. The example shows the use of a closure, that its one (of many) really cool things of Groovy.I'm just quietly giving my opinion in a friendly way. If its to much for you, I apologize and end the discussion here.cheersPedro Costa

"If its too much for me"? Don't worry, I'll be okay. I have an open mind. I'm not married to any language, but an overly expressive block of code against you found up against a contrived example is not something that will make someone unconvinced consider your position.

I've read about closures and as I said, that feature is not compelling enough for me to consider Groovy. I'm just not impressed by any of the scripting languages.

If you are more easily impressed, great! The discussion ends here. :-)

I copyed it from one of the articles, but, I really would like to see your "normal" code to do the same. Please enlight me! I'm sure you will not bore anyone. We will learn!

I hate to bring Spring, but this can be done with spring's use of templates in just about the same amount of lines as in Groovy.

I am not convinced taht Groovy can trim your code all that much. I tried to experiment with GUI building (SWT) in groovy after a while I realized that the reason my Java code looks so long is because I do not abstract enough. After all the abstraction done correctly the length-wise Java program can be just as long as Groovy (after all groovy is done in Java :-))

That is not the point though; I really like Groovy and find it really nice in many respects. Closures are cool, the fact that there is a native syntax for maps and lists is also nice. It is a nice language to learn and see alternatives to Java after a while dealing with Java your mind gets rusty. Learning Groovy can create some new neuron pathways. If nothing else it is just healthy for you :-)

For example, for fast prototyping, imho, no comparison can be done!

You feel that scripting languages are a good choice for prototyping ?

I suspect we're going to have to agree to disagree, when I'm prototyping I want

- Compile time type safety
- To be as close to the real solution as possible
- And to be in an environment I'm familiar with.

I'm a web developer and sometimes I have to code in Javascript, it's pretty close to Java syntactically but it's an absolute pain in the arse because most errors don't appear until runtime.

The thought of using Javascript (or any scripting language) in day to day development. No thanks.

The thought of using Javascript (or any scripting language) in day to day development. No thanks.

I dont know if you ever coded something in Groovy, Python or Ruby, but I can assure you that its really a better experience than Javascript. I really dont like javascript (even I have colleagues that really do great things with it).

You feel that scripting languages are a good choice for prototyping ?

By all means.

I suspect we're going to have to agree to disagree

At last we agree on something!! :)

when I'm prototyping I want
- Compile time type safety
- To be as close to the real solution as possible
- And to be in an environment I'm familiar with.

When I'm prototyping I want to do it as fast and less painfull as I can. I want to be able to express my ideas fast, to see if I'm in the good direction. I dont want to almost finish an algorithm to see if thats what I want.

Talking about compile time type safety, read something from a guy (Bruce Eckel) I really respect, because, in my early days, I learned C++ from his books, then Java again from his books (Thinking in Java) and I started to look at dynamic typed languages following his comments and interest about Python.

Strong Typing vs. Strong Testing:
http://mindview.net/WebLog/log-0025

I'm not expecting that you agree with this, but I think its worth reading.

cheers

Pedro Costa

Mate, these type of bullshit code samples are exactly what gives any initiative a bad name. For example, even though it is supposed to be sexy to do three close statement on rs, conn and stmt, it is from the JDBC API plainly not necessary. If you need to do it,it is because your driver supplier screwed up just like your script language developer might have. Really, these kinds of examples remind me of a meeting my boss once held to promote C++ as a language to create simulations in slab casting as opposed to FORTRAN. He showed a stupid, unstructured peace of FORTRAN code and a nicely structured (and formatted) piece of C++ code.....

Oh, and typing the stuff might be stupid but it is well understood and essentially it is fast and not to error prone in the first place (given we have something like eclipse or idea).

JDBC programming in normal Java: if you know Java it is the same oneliners as in Groovy with all the Connection sharing, transactions and exception handling done by simle and very performant CGLib runtime proxy
http://kgionline.com/articles/aop_1/aop1.jsp

Much cleaner and robust than scripting...

+1 Bruce Tate is right.

I use scripting languages for operations on files, e.g. merging log files. Java is way to complicated for that, a new nice abstraction would be nice. Using iterators over a file system tree defined with regular expressions like the ones used in ant. Greping, seding all the files of the tree would be nice. Thats what perl can do for you with a horrible syntax.
Has groovy anything to ease the work with directory trees and files planned?

A bit OT, but anyone here used Rexx?

The Rexx parse statement has to be the single most powerful statement ever invented in any language. In one line of code, break a string into constituent parts by position, pattern or any combination.

That one statement raised Rexx from mildly interesting to very powerful as a scripting language. If Groovy could implement something similar, I'd be very impressed.

Kit

Hi,

does anybody know if I can use groovy as a scripting language within ant build files? As far as I know, you can only use Apache BSF supported scripting languages. Is groovy such a language?

Regards,
    Dirk

Hi,does anybody know if I can use groovy as a scripting language within ant build files? As far as I know, you can only use Apache BSF supported scripting languages. Is groovy such a language?Regards, Dirk

Why not call the ant tasks directory from java ?

So, rather than inserting Groovy 'scripts' into ant 'scripts' to get the functionality you require, you could write java functions/conditional statements that use all the ant tasks (there just java classes after all).

And you'll get the benefit of

- type safety
- debugger
- not having to learn a scripting language (ant xml)

Hi,does anybody know if I can use groovy as a scripting language within ant build files? As far as I know, you can only use Apache BSF supported scripting languages. Is groovy such a language?Regards, Dirk

Why not call the ant tasks directory from java ?So, rather than inserting Groovy 'scripts' into ant 'scripts' to get the functionality you require, you could write java functions/conditional statements that use all the ant tasks (there just java classes after all).And you'll get the benefit of
- type safety
- debugger
- not having to learn a scripting language (ant xml)

Maybe I did not undestand you correclty. Are you telling me to re-implement an ant-runner, specialized for a single build process? In fact, calling ant tasks directly from within a Java application isn't that easy. Each ant task to be executed needs a certain context, in which it is being executed (all the project stuff, for example), further the ant tasks need to be initialized in a certain way according to the common life-cycle of the tasks. Doing that would be an _enourmous_ overhead (which I wozld have to do for every single build process). Actually I don't see any benefit of doing so.

Type safety:
Type safety to what? Ant tasks? Well, I just put a task tag in an XML file. Either the DTD tells me the task does not exists, or the ant-runner tells me when I execute the build script. Ant support in current IDEs is so good in the meanwhile, that I can life without that type safety _very_ good.

Debugging:
There are debuggers for ant. As far as I know eclipse and netbeans, both, provide an ant debugger.

Not having to learn ant xml:
Well, I don't have to, since I'm quite familiar with ant :-) Also, ant isn't that complex and well documented. I think everyone is able to learn how to write ant scripts in less than a day. Further, if you want to call ant tasks directly from Java you'll have to learn ant's API, which IMHO takes much (_MUCH_) more time than learining how to write an ant script.

Regards,
    Dirk

Hi,does anybody know if I can use groovy as a scripting language within ant build files? As far as I know, you can only use Apache BSF supported scripting languages. Is groovy such a language?Regards,&nbsp;&nbsp;&nbsp;&nbsp;Dirk

Look at this. Maybe its what you are looking for:

http://www-106.ibm.com/developerworks/java/library/j-pg12144.html

Pedro Costa

Hi,does anybody know if I can use groovy as a scripting language within ant build files? As far as I know, you can only use Apache BSF supported scripting languages. Is groovy such a language?Regards,&nbsp;&nbsp;&nbsp;&nbsp;Dirk

Forgot to point you to:

http://groovy.codehaus.org/Ant+Scripting

Hope it helps

Pedro Costa

JSR-223 "Scripting for the Java Platform" should enable Groovy in so many places, including Ant.

Hi,does anybody know if I can use groovy as a scripting language within ant build files? As far as I know, you can only use Apache BSF supported scripting languages. Is groovy such a language?Regards,&nbsp;&nbsp;&nbsp;&nbsp;Dirk

Ant 1.6.2 support using groovy in the script and scriptdef
tasks.
<script language="groovy">
  xmlfiles = new java.io.File(".").listFiles().findAll{ it =~ "\.xml$"}
  xmlfiles.sort().each { self.log(it.toString())}
</script>

I was very enhusiastic with Groovy but what really frustrated me was that there was no up-to-date javadoc on Groovy's site. What is even worse is that it is not possible to build javadoc from the sources. Standard "maven javadoc" command doesn't do anything.