Featured in AI, ML & Data Engineering

In this article, author shows how to use big data query and processing language U-SQL on Azure Data Lake Analytics platform. U-SQL combines the concepts and constructs both of SQL and C#. It combines the simplicity and declarative nature of SQL with the programmatic power of C# including rich types and expressions.

Featured in Culture & Methods

The book Agile Leadership in Practice - Applying Management 3.0 by Dominik Maximini is an experience report of the agile transformation journey of NovaTec. Maximini shares his experiences from applying principles and practices from Management 3.0, success stories, failure stories, and learnings from experiments.

Featured in DevOps

Yuri Shkuro presents a methodology that uses data mining to learn the typical behavior of the system from massive amounts of distributed traces, compares it with pathological behavior during outages, and uses complexity reduction and intuitive visualizations to guide the user towards actionable insights about the root cause of the outages.

What's New in Groovy 1.6

Groovy is a very successful and powerful dynamic language for the Java Virtual Machine that provides seamless integration with Java, and has its roots firmly planted in Java itself for the syntax and APIs and other languages such as Smalltalk, Python or Ruby for its dynamic capabilities.

Groovy is used in many Open Source projects such as Grails, Spring, JBoss Seam and more, as well as integrated in commercial products and Fortune 500 mission-critical applications for its scripting capabilities offering a nice extension mechanism to these applications, or for its ability to let subject matter experts and developers author embedded Domain-Specific Languages to express business concepts in a readable and maintainable fashion.

In this article, Guillaume Laforge, Groovy Project Manager and Head of Groovy Development at SpringSource, will go through an overview of the novelties offered by the newly released Groovy 1.6.

Overview of Groovy 1.6

Related Vendor Content

Related Sponsor

GitLab is a single application for the entire software development lifecycle. Try GitLab for free.

As we shall see in this article, the main highlights of this Groovy 1.6 release are:

Greater compile-time and runtime performance improvements

Multiple assignments

Optional return in if/else and try/catch blocks

Java 5 annotation definition

AST transformations and all the provided transformation annotations like @Singleton, @Lazy, @Immutable, @Delegate and friends

The Grape module and dependency system and its @Grab transformation

Various Swing builder improvements, thanks to the Swing / Griffon team, as well as several Swing console improvements

The integration of JMX builder

Various metaprogramming improvements, like the EMC DSL, per-instance metaclasses even for POJOs, and runtime mixins

JSR-223 scripting engine built-in

Out-of-the-box OSGi readiness

All those improvements and new features serve one goal: helping developers be more productive and more agile, by:

Focusing more on the task at hand than on boiler-plate technical code

Leveraging existing Enterprise APIs rather than reinventing the wheel

Improving the overal performance and quality of the language

Enabling developers to customize the language at will to derive their own Domain-Specific Languages

But beyond all these important aspects, Groovy is not just a language, it's a whole ecosystem.

The improvements in Groovy's generated bytecode information helps capable tools coverage like Cobertura and its Groovy support, or pave the way for new utilities like CodeNarc for static code analysis for Groovy.

The malleability of the syntax of the language and its metaprogramming capabilities give birth to advanced testing tools such as the Easyb Behavior-Driven-Development project, the GMock mocking library or the Spock testing and specification framework.

Again, Groovy's flexibility and expressivity and its scripting capabilities open the doors to advanced build scripting or infrastructure systems for your continuous integration practices and project build solutions, such as Gant and Graddle.

At the tooling level, Groovy also progresses, for instance with its groovydoc Ant task to let you generate proper JavaDoc covering, documenting and interlinking both your Groovy and Java source files for your Groovy/Java mixed projects.

And at the same time, IDE makers improve their support for Groovy, by giving users powerful weapons such as cross-language code refactoring, profound understanding of dynamic language idioms, code completion, and more, to make developers productive when using Groovy in their projects.

Now, armed with this knowledge of the Groovy world, it's time to dive into the novelties of Groovy 1.6!

Performance improvements

A lot of care has been taken to improve both the compile-time and runtime performance of Groovy, compared to previous releases.

The compiler is 3 to 5 times faster than in previous releases. This improvement has also been backported in the 1.5.x branch, so that both the old maintenance branch and the current stable branch benefit from this work. Thanks to class lookup caches, the bigger the project, the faster the compilation will be.

However, the most noticeable changes will be in the general runtime performance improvements of Groovy. We used several benchmarks from the Great Language Shootout to measure our progress. On those we selected, compared to the old Groovy 1.5.x line, the performance improvements ranged from 150% to 460%. Micro-benchmarks obviously rarely reflect the kind of code you have in your own projects, but the overal performance of your projects should improve significantly.

Multiple assignments

In Groovy 1.6, there is only one syntax addition for being able to define and assign several variables at once:

def (a, b) = [1, 2]
assert a == 1
assert b == 2

A more meaninful example may be methods returning longitute and latitude coordinates. If these coordinates are represented as a list of two elements, you can easily get back to each element as follows:

If the list on the right-hand side contains more elements than the number of variables on the left-hand side, only the first elements will be assigned in order into the variables. Also, when there are less elements than variables, the extra variables will be assigned null.

So for the case with more variables than list elements, here, c will be null:

Annotation definition

Actually, when I said that multiple assignments were the sole syntax addition, it's not entirely true. Groovy supported the syntax for annotation definition even in Groovy 1.5, but we had not implemented the feature completely. Fortunately, this is now fixed, and it wraps up all the Java 5 features supported by Groovy, such as static imports, generics, annotations, and enums, making Groovy the sole alternative dynamic language for the JVM supporting all those Java 5 features, which is critical for a seamless Java integration story, and for the usage in Enterprise frameworks relying on annotations, generics and more, like JPA, EJB3, Spring, TestNG, etc.

Optional return for if/else and try/catch/finally blocks

It is now possible for if/else and try/catch/finally blocks to return a value when they are the last expression in a method or a closure. No need to explicitly use the return keyword inside these constructs, as long as they are the latest expression in the block of code.

As an example, the following method will return 1, although the return keyword was omitted.

def method() {
if (true) 1 else 0
}
assert method() == 1

For try/catch/finally blocks, the last expression evaluated is the one being returned. If an exception is thrown in the try block, the last expression in the catch block is returned instead. Note that finally blocks don't return any value.

AST Transformations

Although at times, it may sound like a good idea to extend the syntax of Groovy to implement new features (like this is the case for instance for multiple assignments), most of the time, we can't just add a new keyword to the grammar, or create some new syntax construct to represent a new concept. However, with the idea of AST (Abstract Syntax Tree) Transformations, we are able to tackle new and innovative ideas without necessary grammar changes.

When the Groovy compiler compiles Groovy scripts and classes, at some point in the process, the source code will end up being represented in memory in the form of a Concrete Syntax Tree, then transformed into an Abstract Syntax Tree. The purpose of AST Transformations is to let developers hook into the compilation process to be able to modify the AST before it is turned into bytecode that will be run by the JVM.

There are two kinds of transformations: global and local transformations.

Global transformations are applied to by the compiler on the code being compiled, wherever the transformation apply. A JAR added to the classpath of the compiler should contain a service locator file at META-INF/services/org.codehaus.groovy.transform.ASTTransformation with a line with the name of the transformation class. The transformation class must have a no-args constructor and implement the org.codehaus.groovy.transform.ASTTransformation interface. It will be run against every source in the compilation, so be sure to not create transformations which scan all the AST in an expansive and time-consuming manner, to keep the compiler fast.

Local transformations are transformations applied locally by annotating code elements you want to transform. For this, we reuse the annotation notation, and those annotations should implement org.codehaus.groovy.transform.ASTTransformation. The compiler will discover them and apply the transformation on these code elements.

Groovy 1.6 provides several local transformation annotations, in the Groovy Swing Builder for data binding (@Bindable and @Vetoable), in the Grape module system for adding script library dependencies (@Grab), or as general language features without requiring any syntax change to support them (@Singleton, @Immutable, @Delegate, @Lazy, @Newify, @Category, @Mixin and @PackageScope). Let's have a look at some of these transformations (@Bindable and @Vetoable will be covered in the section related to the Swing enhancements, and @Grab in the section about Grape).

@Singleton

Whether the singleton is pattern or an anti-pattern, there are still some cases where we need to create singletons. We're used to create a private constructor, a getInstance() method for a static field or even an initialized public static final field. So instead of writing code like this in Java:

Lazy or not, once again, to access the instance, simply do T.instance (property access, shorcut for T.getInstance()).

@Immutable

Immutable objects are ones which don't change after initial creation. Such objects are frequently desirable because they are simple and can be safely shared even in multi-threading contexts. This makes them great for functional and concurrent scenarios. The rules for creating such objects are well-known:

No mutators (methods that modify internal state)

Class must be final

Fields must be private and final

Defensive copying of mutable components

equals(), hashCode() and toString() must be implemented in terms of the fields if you want to compare your objects or use them as keys in e.g. maps

Instead of writing a very long Java or Groovy class mimicking this immutability behavior, Groovy lets you just write an immutable class as follow:

All the boiler-plate code is generated at compile-time for you! The example shows that to instantiate such immutable coordinates, you can use one of the two constructors created by the transformation, one taking a map whose keys are the properties to set to the values associated with those keys, and the other taking the values of the properties as parameters. The assert also shows that equals() was implemented and allows us to properly compare such immutable objects.

You can have a look at the details of the implementation of this transformation. For the record, the Groovy example above using the @Immutable transformation is over 50 lines of equivalent Java code.

@Lazy

Another transformation is @Lazy. Sometimes, you want to handle the initialization of a field of your clas lazily, so that its value is computed only on first use, often because it may be time-consuming or memory-expensive to create. The usual approach is to customize the getter of said field, so that it takes care of the initialization when the getter is called the first time. But in Groovy 1.6, you can now use the @Lazy annotation for that purpose:

In the case of complex computation for initializing the field, you may need to call some method for doing the work, instead of a value like our pets list. This is then possible to have the lazy evaluation being done by a closure call, as the following example shows:

The internal field created by the compiler for pets will actually be a Soft reference, but accessing p.pets directly will return the value (ie. the list of pets) held by that reference, making the use of the soft reference transparent to the user of that class.

@Delegate

Java doesn't provide any built-in delegation mechanism, and so far Groovy didn't either. But with the @Delegate transformation, a class field or property can be annotated and become an object to which method calls are delegated. In the following example, an Event class has a date delegate, and the compiler will delegate all of Date's methods invoked on the Event class to the Date delegate. As shown in the latest assert, the Event class has got a before(Date) method, and all of Date's methods.

The Groovy compiler adds all of Date's methods to the Event class, and those methods simply delegate the call to the Date field. If the delegate is not a final class, it is even possible to make the Event class a subclass of Date simply by extending Date, as shown below. No need to implement the delegation ourselves by adding each and every Date methods to our Event class, since the compiler is friendly-enough with us to do the job itself.

class Event extends Date {
@Delegate Date when
String title, url
}

In the case you are delegating to an interface, however, you don't even need to explictely say you implement the interface of the delegate. The @Delegate transformation will take care of this and implement that interface. So the instances of your class will automatically be instanceof the delegate's interface.

In this example, our LockableList is now a composite of a list and a lock and is instanceof of List and Lock. However, if you didn't intend your class to be implementing these interfaces, you would still be able to do so by specifying a parameter on the annotation:

@Delegate(interfaces = false) private List list = []

@Newify

The @Newify transformation proposes two new ways of instantiating classes. The first one is providing Ruby like approach to creating instances with a new() class method:

@Newify rubyLikeNew() {
assert Integer.new(42) == 42
}
rubyLikeNew()

But it is also possible to follow the Python approach with omitting the new keyword. Imagine the following tree creation:

The creation of the tree is not very readable because of all those new keywords spread across the line. The Ruby approach wouldn't be more readable, since a new() method call for creating each element is needed. But by using @Newify, we can improve our tree building slightly to make it easier on the eye:

You'll also notice that we just allowed Tree and Leaf to be newified. By default, under the scope which is annotated, all instantiations are newified, but you can limit the reach by specifying the classes you're interested in. Also, note that for our example, perhaps a Groovy builder may have been more appropriate, since its purpose is to indeed create any kind of hierarchical / tree strucutre.

If we take another look at our coordinates example from a few sections earlier, using both @Immutable and @Newify can be interesting for creating a path with a concise but type-safe manner:

A closing remark here: since a Path(Coordinates[] coordinates) was generated, we can use that constructor in a varargs way in Groovy, just as if it had been defined as Path(Coordinates... coordinates).

@Category and @Mixin

If you've been using Groovy for a while, you're certainly familiar with the concept of Categories. It's a mechanism to extend existing types (even final classes from the JDK or third-party libraries), to add new methods to them. This is also a technique which can be used when writing Domain-Specific Languages. Let's consider the example below:

We have a simplistic and fictive Distance class which may have been provided by a third-party, who had the bad idea of making the class final so that nobody could ever extend it in any way. But thanks to a Groovy Category, we are able to decorate the Distance type with additional methods. Here, we're going to add a getMeters() method to numbers, by actually decorating the Number type. By adding a getter to a number, you're able to reference it using the nice property syntax of Groovy. So instead of writing 300.getMeters(), you're able to write 300.meters.

The downside of this category system and notation is that to add instance methods to other types, you have to create static methods, and furthermore, there's a first argument which represents the instance of the type we're working on. The other arguments are the normal arguments the method will take as parameters. So it may be a bit less intuitive than a normal method definition we would have added to Distance, should we have had access to its source code for enhancing it. Here comes the @Category annotation, which transforms a class with instance methods into a Groovy category:

No need for declaring the methods static, and the this you use here is actually the number on which the category will apply, it's not the real this of the category instance should we create one. Then to use the category, you can continue to use the use(Category) {} construct. What you'll notice however is that these kind of categories only apply to one single type at a time, unlike classical categories which can be applied to any number of types.

Now, pair @Category extensions to the @Mixin transformation, and you can mix in various behavior in a class, with an approach similar to multiple inheritance:

You don't inherit from various interfaces and inject the same behavior in each subclass, instead you mixin the categories into your class. Here, our marvelous James Bond vehicle gets the flying and diving capabilities through mixins.

An important point to make here is that unlike @Delegate which can inject interfaces into the class in which the delegate is declared, @Mixin just does runtime mixing — as we shall see in the metaprogramming enhancements further down in this article.

@PackageScope

Groovy's convention for properties is that any field without any visibility modifier is exposed as a property, with a getter and a setter transparently generated for you. For instance, this Person class exposes a getter getName() and a setter setName() for a private name field:

That said, this approach has one drawback in that you don't have the possibility to define a field with package-scope visibility. To be able to expose a field with package-scope visibility, you can now annotate your field with the @PackageScope annotation.

Grape, the Groovy Adaptable / Advanced Packaging Engine

To continue our overview of the AST transformations, we'll now learn more about Grape, a mechanism to add and leverage dependencies in your Groovy scripts. Groovy scripts can require certain libraries: by explicitly saying so in your script with the @Grab transformation or with the Grape.grab() method call, the runtime will find the needed JARs for you. With Grape, you can easily distribute scripts without their dependencies, and have them downloaded on first use of your script and cached. Under the hood, Grape uses Ivy and Maven repositories containing the libraries you may need in your scripts.

Imagine you want to get the links of all the PDF documents referenced by the Java 5 documentation. You want to parse the HTML page as if it were an XML-compliant document (which it is not) with the Groovy XmlParser, so you can use the TagSoup SAX-compliant parser which transforms HTML into well-formed valid XML. You don't even have to mess up with your classpath when running your script, just grab the TagSoup library through Grape:

Grape will download Jetty and its dependencies on first launch of this script, and cache them. We're creating a new Jetty Server on port 8080, then expose Groovy's TemplateServlet at the root of the context — Groovy comes with its own powerful template engine mechanism. We start the server and let it run for a certain duration. Each time someone will hit http://localhost:8080/somepage.gsp, it will display the somepage.gsp template to the user — those template pages should be situated in the same directory as this server script.

Grape can also be used as a method call instead of as an annotation. You can also install, list, resolve dependencies from the command-line using the grape command. For more information on Grape, please refer to the documentation.

Swing builder improvements

To wrap up our overview of AST transformations, let's finish by speaking about two transformations very useful to Swing developers: @Bindable and @Vetoable. When creating Swing UIs, you're often interested in monitoring the changes of value of certain UI elements. For this purpose, the usual approach is to use JavaBeans PropertyChangeListeners to be notified when the value of a class field changes. You then end up writing this very common boiler-plate code in your Java beans:

Along with @Bindable, there's also a @Vetoable transformation for when you need to be able to veto some property change. Let's consider a Trompetist class, where the performer's name is not allowed to contain the letter 'z':

Running this script shows up the frame below with a text field and a lable below, and the label's text is bound on the text field's content.

SwingBuilder has evolved so nicely in the past year that the Groovy Swing team decided to launch a new project based on it, and on the Grails foundations: project Griffon was born. Griffon proposes to bring the Convention over Configuration paradigm of Grails, as well as all its project structure, plugin system, gant scripting capabilities, etc.

If you are developing Swing rich clients, make sure to have a look at Griffon.

Back on the visualization of the results in the script output area, a fun system was added to let you customize how certain results are rendered. When you execute a script returning a map of Jazz musicians, you may see something like this in your console:

What you see here is the usual textual representation of a Map. But, what if we enabled custom visualization of certain results? The Swing console allows you to do just that. First of all, you have to ensure that the visualization option is ticked: View -> Visualize Script Results — for the record, all settings of the Groovy Console are stored and remembered thanks to the Preference API. There are a few result visualizations built-in: if the script returns a java.awt.Image, a javax.swing.Icon, or a java.awt.Component with no parent, the object is displayed instead of its toString() representation. Otherwise, everything else is still just represented as text. Now, create the following Groovy script in ~/.groovy/OutputTransforms.groovy:

The Groovy Swing console will execute that script on startup, injecting a transforms list in the binding of the script, so that you can add your own script results representations. In our case, we transform the Map into a nice-looking Swing JTable. And we're now able to visualize maps in a friendly and attractive fashion, as the screenshot below shows:

The Swing console is obviously not to be confused with a real full-blown IDE, but for daily scripting tasks, the console is a handy tool in your toolbox.

Metaprogramming enhancements

What makes Groovy a dynamic language is its Meta-Object Protocol and its concept of metaclasses which represent the runtime behavior of your classes and instances. In Groovy 1.6, we continue improving this dynamic runtime system, bringing several new capabilities into the mix.

Per instance metaclass even for POJOs

So far, Groovy POGOs (Plain Old Groovy Objects) could have a per-instance metaclass, but POJOs could only have one metaclass for all instances (ie. a per-class metaclass). This is now not the case anymore, as POJOs can have a per-instance metaclass too. Also, setting the metaclass property to null will restore the default metaclass.

ExpandoMetaClass DSL

Initially developed under the Grails umbrella and integrated back into Groovy 1.5, ExpandoMetaClass is a very handy way for changing the runtime behavior of your objects and classes, instead of writing full-blow MetaClass classes. Each time, we want to add / change several properties or methods of an existing type, there is too much of a repetition of Type.metaClass.xxx. Take for example this extract of a Unit manipulation DSL dealing with operator overloading:

A metaClass() method takes a closure as single argument, containing the various definitions of the methods and properties, instead of repeating the Type.metaClass on each line. When there is just one method of a given name, use the pattern methodName { /* closure */ }, but when there are several, you should use the append operator and follow the patten methodName << { /* closure */ }. Static methods can also be added through this mechanism, so instead of the classical approach:

Note here that you have to quote the static keyword, to avoid this construct to look like a static initializer. For one off method addition, the classical approach is obviously more concise, but when you have several methods to add, the EMC DSL makes sense.

The usual approach for adding properties to existing classes through ExpandoMetaClass is to add a getter and a setter as methods. For instance, say you want to add a method that counts the number of words in a text file, you could try this:

When there is some logic inside the getter, this is certainly the best approach, but when you just want to have new properties holding simple values, through the ExpandoMetaClass DSL, it is possible to define them. In the following example, a lastAccessed property is added to a Car class — each instance will have its property. Whenever a method is called on that car, this property is updated with a newer timestamp.

In our example, in the DSL, we access that property through the delegate of the closure, with delegate.lastAccessed = new Date(). And we intercept any method call thanks to invokeMethod(), delegating to the original method for the call, and throwing an exception in case the method doesn't exist. Later on, you can see by executing this script that lastAccessed is updated as soon as we call a method on our instance.

Runtime mixins

Last metaprogramming feature we'll cover today: runtime mixins. @Mixin allowed you to mixin new behavior to classes you owned and were designing. But you could not mixin anything to types you didn't own. Runtime mixins propose to fill that gap by letting you add a mixin on any type at runtime. If we think again about our example of vehicles with some mixed-in capabilities, if we didn't own James Bond's vehicle and give it some diving ability, we could use this mechanism:

One or more mixins can be passed as argument to the static mixin() method added by Groovy on Class.

JSR-223 Groovy Scripting Engine

Before Groovy 1.6, if you wanted to integrate Groovy in your Java projects through JSR-223 / javax.script.*, you had to download a Groovy script engine implementation from java.net, and put the JAR in your classpath. This additional step wasn't very developer friendly, requiring some additional work — the JAR wasn't even provided in the Groovy distribution. Thankfully, 1.6 comes with an implementation of the javax.script.* APIs.

Below, you'll find an example evaluating Groovy expressions (the code is in Groovy, but it's straightforward to convert it back to Java):

Please note that the javax.script.* APIs are available only on Java 6.

JMX Builder

Originiating as an external Open-Source project hosted on Google Code, JMX Builder has been integrated in Groovy 1.6, to simplify the life of developers needing to interact or expose JMX services. JMX Builder features:

You can find more information on JMX Builder and its very extensive coverage of the JMX system. Lots of examples will show you how to create a JMX connector server or client, how to easily export POGOs as JMX managed beans, how to listen to JMX events, and much more.

Improved OSGi support

The Groovy jar files are released with correct OSGi metadata, so they can be loaded as a bundle into any OSGi compliant container, such as Eclipse Equinox or Apache Felix. You can find more information on how to use Groovy and OSGi on the Groovy project website. This tutorial will explain how to:

Summary

Groovy continues its march towards the goal of simplifying the life of developers, providing various new features and improvements in this new release: AST transformations reducing dramatically the number of lines of code to express certain concerns and patterns and opening the language to developers for further extension, several metaprogramming enhancements to streamline your code and let you write more expressive business rules, and support for common enterprise APIs such as Java 6's scripting APIs, JMX management system, or OSGi's programming model. All of this is done obviously without compromising on the seamless integration with Java, and furthermore, with a level of performance way higher than previous releases.

We've now reached the end of this article and if you're not a Groovy user yet, I hope this artcile will give you a better understanding of what Groovy has to offer in your projects, and if you knew and used Groovy already, that you learned about all the new features of the language. The next step for you, dear reader, is to go download Groovy 1.6. And if you wish to dive deeper into Groovy, Grails and Griffon, I also invite you to join us at the GR8 Conference, a conference dedicated to Groovy, Grails and Griffon, taking place in Copenhagen, Denmark, where experts and makers of these technologies will guide you through with practical presentations and hands-on labs.

About the author

As Head of Groovy Development for SpringSource, Guillaume Laforge is the official Groovy Project Manager, and the spec lead of JSR-241, the Java Specification Request that standardizes the Groovy dynamic language. He is also a frequent conference speaker presenting Groovy and Grails at JavaOne, SpringOne, QCon, the Sun TechDays, and JavaPolis/Devoxx. Guillaume also co-authored Groovy in Action along with Dierk König. Before founding G2One, the Groovy/Grails company, which was acquired by SpringSource in late 2008, and taking the role of VP Technology, Guillaume worked for OCTO Technology, a consultancy focusing on architecture and agile methodologies. While at OCTO, Guillaume developed new offerings around Groovy and Grails for its customers.

Good Job !

Your message is awaiting moderation. Thank you for participating in the discussion.

Groovy is really becoming my favorite scripting language. Any speed improvement is welcome even for day to day scripting tasks but it is even more important for use in mainstream commercial application.

Immutable objects

Your message is awaiting moderation. Thank you for participating in the discussion.

Great to see that the groovy team is embracing immutability as a critical part of the language.

Can methods require @immutable arguments and return types? That would make it possible to write side effect free functions that can be parallelized. If the compiler can enforce immutability, then it would be trivial to write an erlang-like messaging library or a a parallelized linear algebra implementation.

Also, immutable types should also generate modifiers for all properties. Otherwise, working with immutable types is cumbersome and involves a lot of boilerplate copying of fields between objects.

Awesome!

Your message is awaiting moderation. Thank you for participating in the discussion.

This is a truly great achievement! Not only are there performance improvements but all of that added jazz (AST Transformations). I did not realize what the AST transformations did until I read this release article and I am truly amazed.It's great that you've added full annotation support, because that makes Groovy code truly more Java-esque. I think after this release Groovy is going to get much more attention that it so truly deserves!When is the standalone Gorm coming? I am really looking forward to that (Hope I'm not asking too much).

@Singleton and double checked locking

Your message is awaiting moderation. Thank you for participating in the discussion.

Very impressive! Only one comment: it seems @Singleton uses the problematic double checked locking. I suggest using the private static class method that does not even need explicit locking - seestackoverflow.com/questions/70689/efficient-way... .Hans-Peter

Scripting against different APIs leads to many castings to appropriate types desired by API methods (e.g. frequently casting to various Arrays). Its not always clear what type Groovy uses natively. This should be seamless.

Adding classpath in script to current GroovyClassLoader still causes script to not recognize classes used right after - groovy is not dynamic enough..haha. I have to use reflection(e.g. Classloader.loadClass()) for all newly added classpaths.

Scoping of variables with/without def and with/without types (like Java) is confusing. Scripts cannot access variables defined in another script even if via a method inside that script (but instantiation and method invokation of that script works as long as no variables are accessed!!). Named inner classes cannot access surrounding scope.

Spent a good hour+ figuring out why something wasn't happenning as expected - later found out my override of an API method was silently returning false. I had forgotten to return a value for the boolean method() - no errors given.

There are several Java language features gotchas that are not implemented as expected (so "code in Java" is not always a correct stmt) - I can't remember them now - i just worked around them.

I am sure there are good reasons for all the above - but my point is - things listed above are going to be the first things a Java guy tries and expects them to just work.

Re: Nice but some issues with Groovy...

Your message is awaiting moderation. Thank you for participating in the discussion.

Multi variable returns, assignments and swaps is a feature i've always longed - so that is great. And the other features look fabulous as well.

Cool, I'm glad you like them.

I've only newly embraced groovy for general scripting use and quick prototyping - but here are some issues I've run into constantly.. Correct me on any of them..

Inability to create anonymous classes easily to pass into various APIs being scripted (e.g. Eclipse API or Thread/Process API).

Groovy provides a couple mechanisms for that, with map and closure coercion, like {} as SomeInterface (for interfaces with just one method), or even [meth1:{}, meth2:{}] as SomeOtherInterface (for when you need to implement or extend several methods).

In Groovy 1.7, we'll be adding raw / classical anonymous inner classes, even though they're not really necessary per se in most situations.

Scripting against different APIs leads to many castings to appropriate types desired by API methods (e.g. frequently casting to various Arrays). Its not always clear what type Groovy uses natively. This should be seamless.

There are some occasions where we need casting, but they're not very frequent.Unlike a statically compiled language, you have to remember that a dynamic language chooses methods at runtime, according to the runtime type of the parameters passed to the method you're calling. So that difference makes that sometimes you need to help the dynamic runtime know which method you really intended to call.That said, some precise examples would be needed, because that statement doesn't help much, I'm afraid.

Adding classpath in script to current GroovyClassLoader still causes script to not recognize classes used right after - groovy is not dynamic enough..haha. I have to use reflection(e.g. Classloader.loadClass()) for all newly added classpaths.

Again, an example would be helpful, as I'm sure we can find a neater solution here.

Scoping of variables with/without def and with/without types (like Java) is confusing. Scripts cannot access variables defined in another script even if via a method inside that script (but instantiation and method invokation of that script works as long as no variables are accessed!!). Named inner classes cannot access surrounding scope.

Variables not def'ed or without types, in scripts, go into the binding of the script.Otherwise, def'ed and typed variables are just "local" variables. Local to your script, so that's normal (and as designed) that they are not available to other scripts.If you need to share variables, you'd better share the same binding for all your scripts.

As for named inner classes, I'm not sure I understand what you mean here.If it's in scripts again, if you want to access local variables, they are indeed local to the script, a bit like if you added a local variable to your main() method. So they indeed can't be seen from another class defined in your script. So, again, you use the binding (don't def/don't type your variables). That seems like what's best for your use case, it seems.

Spent a good hour+ figuring out why something wasn't happenning as expected - later found out my override of an API method was silently returning false. I had forgotten to return a value for the boolean method() - no errors given.

That's because of optional return.If your forget to return anything, the latest statement of your method will be evaluated to a boolean.

There are several Java language features gotchas that are not implemented as expected (so "code in Java" is not always a correct stmt) - I can't remember them now - i just worked around them.

There aren't many differences left with Java anyway, apart from anonymous inner classes, for instance, or array initializers. Otherwise, the "compatibility" is very high.

I am sure there are good reasons for all the above - but my point is - things listed above are going to be the first things a Java guy tries and expects them to just work.

When you're encountering problems, please report them on the Groovy user mailing-list, you'll get very fast responses to all your questions.Furthermore, remember that Groovy is a dynamic language, so there are obviously some differences with Java from times to times, but it's close to Java enough to be very easy to get started with.

@Delegate-Annotation

Your message is awaiting moderation. Thank you for participating in the discussion.

Multiple-Inheritance without AspectJ - I love this feature. What will happen if two or more delegates implement the same method signature, which one is called? What happens if my own class implements that method signature too? Is there a way to specify which class's method should be called in that scenario (like in C++ Class::method)?

Really amazing features

Your message is awaiting moderation. Thank you for participating in the discussion.

Great job with all of the enhancements. I'm especially impressed, almost to the point of intimidation, by the AST Transformation features. They let you do almost anything. The only detriment that I can see (and that I'm willing to live with) is the magic factor: so much is going on behind the scenes that you wouldn't know about otherwise. The use of annotations to drive the AST Transformations is a nice way, however, to indicate to readers of the source "Hey, something special is happening here, so you'd better either know what it is or go look it up."