You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@groovy.apache.org by pa...@apache.org on 2017/04/25 23:06:05 UTC
[05/20] groovy-user-site git commit: move content to asf-site branch
http://git-wip-us.apache.org/repos/asf/groovy-user-site/blob/de805f31/site/src/site/releasenotes/groovy-1.6.adoc
----------------------------------------------------------------------
diff --git a/site/src/site/releasenotes/groovy-1.6.adoc b/site/src/site/releasenotes/groovy-1.6.adoc
deleted file mode 100644
index cf4e2c1..0000000
--- a/site/src/site/releasenotes/groovy-1.6.adoc
+++ /dev/null
@@ -1,1436 +0,0 @@
-== Overview of Groovy 1.6
-
-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
-/�link:http://griffon-framework.org/[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\u2019s a whole ecosystem*.
-
-The improvements in Groovy\u2019s generated bytecode information helps
-capable tools coverage
-like�link:http://cobertura.github.io/cobertura/[Cobertura]�and
-its Groovy support, or pave the way for new utilities
-like�link:http://codenarc.sourceforge.net/[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 link:http://easyb.org/[Easyb]�Behavior-Driven-Development project,
-the�link:http://code.google.com/p/gmock/[GMock]�mocking library or
-the�link:http://code.google.com/p/spock/[Spock]�testing and specification
-framework.
-
-Again, Groovy\u2019s 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�link:https://gant.github.io/[Gant]�and�link:http://www.gradle.org/[Gradle].
-
-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\u2019s time to dive
-into the novelties of Groovy 1.6!
-
-[[Groovy16releasenotes-Performanceimprovements]]
-== 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�link:http://shootout.alioth.debian.org/[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.
-
-[[Groovy16releasenotes-Multipleassignments]]
-== Multiple assignments
-
-In Groovy 1.6, there is only one syntax addition for being able to
-define and assign several variables at once:
-
-[source,groovy]
--------------------
-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:
-
-[source,groovy]
----------------------------------------------------------------------
-def geocode(String location) {
- // implementation returns [48.824068, 2.531733] for Paris, France
-}
-
-def (lat, long) = geocode("Paris, France")
-
-assert lat == 48.824068
-assert long == 2.531733
----------------------------------------------------------------------
-
-And you can also define the types of the variables in one shot as
-follows:
-
-[source,groovy]
--------------------------------------
-def (int i, String s) = [1, 'Groovy']
-
-
-assert i == 1
-assert s == 'Groovy'
--------------------------------------
-
-For the assignment (with prior definition of the variables), just omit
-the�`def`�keyword:
-
-[source,groovy]
-------------------------------------------------------
-def firstname, lastname
-
-
-(firstname, lastname) = "Guillaume Laforge".tokenize()
-
-
-assert firstname == "Guillaume"
-assert lastname == "Laforge"
-------------------------------------------------------
-
-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`:
-
-[source,groovy]
-------------------------
-def elements = [1, 2]
-def (a, b, c) = elements
-
-
-assert a == 1
-assert b == 2
-assert c == null
-------------------------
-
-Whereas in the case where there are more list elements than variables,
-we\u2019ll get the following expectations:
-
-[source,groovy]
----------------------------
-def elements = [1, 2, 3, 4]
-def (a, b, c) = elements
-
-
-assert a == 1
-assert b == 2
-assert c == 3
----------------------------
-
-For the curious minds, supporting multiple assignments also means we can
-do the standard school swap case in one line:
-
-[source,groovy]
------------------------------
-// given those two variables
-def a = 1, b = 2
-
-
-// swap variables with a list
-(a, b) = [b, a]
-
-
-assert a == 2
-assert b == 1
------------------------------
-
-[[Groovy16releasenotes-Annotationdefinition]]
-== Annotation definition
-
-Actually, when I said that multiple assignments were the sole syntax
-addition, it\u2019s 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.
-
-[[Groovy16releasenotes-Optionalreturnforifelseandtrycatchfinallyblocks]]
-== 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.
-
-[source,groovy]
-----------------------
-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\u2019t return any value.
-
-[source,groovy]
---------------------------------------------
-def method(bool) {
- try {
- if (bool) throw new Exception("foo")
- 1
- } catch(e) {
- 2
- } finally {
- 3
- }
-}
-
-
-assert method(false) == 1
-assert method(true) == 2
---------------------------------------------
-
-[[Groovy16releasenotes-ASTTransformations]]
-== 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\u2019t 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.
-
-*AST Transformations provides Groovy with improved compile-time
-metaprogramming capabilities*�allowing powerful flexibility at the
-language level, without a runtime performance penalty.
-
-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\u2019s 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).
-
-[[Groovy16releasenotes-Singleton]]
-=== @Singleton
-
-Whether the singleton is pattern or an anti-pattern, there are still
-some cases where we need to create singletons. We\u2019re 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:
-
-[source,groovy]
----------------------------------------------
-public class T {
- public static final T instance = new T();
- private T() {}
-}
----------------------------------------------
-
-You just need to annotate your type with the�`@Singleton`�annotation:
-
-[source,groovy]
----------------------
-@Singleton class T {}
----------------------
-
-The singleton instance can then simply be accessed
-with�`T.instance`�(direct public field access).
-
-You can also have the lazy loading approach with an additional
-annotation parameter:
-
-[source,groovy]
-----------------------------------
-@Singleton(lazy = true) class T {}
-----------------------------------
-
-Would become more or less equivalent to this Groovy class:
-
-[source,groovy]
----------------------------------------
-class T {
- private static volatile T instance
- private T() {}
- static T getInstance () {
- if (instance) {
- instance
- } else {
- synchronized(T) {
- if (instance) {
- instance
- } else {
- instance = new T ()
- }
- }
- }
- }
-}
----------------------------------------
-
-Lazy or not, once again, to access the instance, simply
-do�`T.instance`�(property access, shorcut for�`T.getInstance()`).
-
-[[Groovy16releasenotes-Immutable]]
-=== @Immutable
-
-Immutable objects are ones which don\u2019t 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:
-�
-[source,groovy]
-------------------------------------------------------------------
-@Immutable final class Coordinates {
- Double latitude, longitude
-}
-
-
-def c1 = new Coordinates(latitude: 48.824068, longitude: 2.531733)
-def c2 = new Coordinates(48.824068, 2.531733)
-
-
-assert c1 == c2
-------------------------------------------------------------------
-
-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�link:http://docs.groovy-lang.org/latest/html/gapi/groovy/transform/Immutable.html[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.
-
-[[Groovy16releasenotes-Lazy]]
-=== @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:
-
-[source,groovy]
----------------------------------------
-class Person {
- @Lazy pets = ['Cat', 'Dog', 'Bird']
-}
-
-
-def p = new Person()
-assert !(p.dump().contains('Cat'))
-
-assert p.pets.size() == 3
-assert p.dump().contains('Cat')
----------------------------------------
-
-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:
-
-[source,groovy]
-----------------------------------------------------------
-class Person {
- @Lazy List pets = { /* complex computation here */ }()
-}
-----------------------------------------------------------
-
-There is also an option for leveraging Soft references for garbage
-collection friendliness for expensive data structures that may be
-contained by such lazy fields:
-
-[source,groovy]
----------------------------------------------------------
-class Person {
- @Lazy(soft = true) List pets = ['Cat', 'Dog', 'Bird']
-}
-
-
-def p = new Person()
-assert p.pets.contains('Cat')
----------------------------------------------------------
-
-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.
-
-[[Groovy16releasenotes-Delegate]]
-=== @Delegate
-
-Java doesn\u2019t provide any built-in delegation mechanism, and so far
-Groovy didn\u2019t 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`\u2019s 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`\u2019s methods.
-
-[source,groovy]
---------------------------------------------------------------
-import java.text.SimpleDateFormat
-
-
-class Event {
- @Delegate Date when
- String title, url
-}
-
-
-def df = new SimpleDateFormat("yyyy/MM/dd")
-
-
-def gr8conf = new Event(title: "GR8 Conference",
- url: "http://www.gr8conf.org",
- when: df.parse("2009/05/18"))
-def javaOne = new Event(title: "JavaOne",
- url: "http://java.sun.com/javaone/",
- when: df.parse("2009/06/02"))
-
-assert gr8conf.before(javaOne.when)
---------------------------------------------------------------
-
-The Groovy compiler adds all of�`Date`\u2019s 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.
-
-[source,groovy]
---------------------------
-class Event extends Date {
- @Delegate Date when
- String title, url
-}
---------------------------
-
-In the case you are delegating to an interface, however, you don\u2019t 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\u2019s interface.
-
-[source,groovy]
------------------------------------------------------
-import java.util.concurrent.locks.*
-
-
-class LockableList {
- @Delegate private List list = []
- @Delegate private Lock lock = new ReentrantLock()
-}
-
-
-def list = new LockableList()
-
-
-list.lock()
-try {
- list << 'Groovy'
- list << 'Grails'
- list << 'Griffon'
-} finally {
- list.unlock()
-}
-
-
-assert list.size() == 3
-assert list instanceof Lock
-assert list instanceof List
------------------------------------------------------
-
-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\u2019t
-intend your class to be implementing these interfaces, you would still
-be able to do so by specifying a parameter on the annotation:
-
-[source,groovy]
-----------------------------------------------------
-@Delegate(interfaces = false) private List list = []
-----------------------------------------------------
-
-[[Groovy16releasenotes-Newify]]
-=== @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:
-
-[source,groovy]
---------------------------------
-@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:
-
-[source,groovy]
------------------------------------------------------------------
-class Tree {
- def elements
- Tree(Object... elements) { this.elements = elements as List }
-}
-
-
-class Leaf {
- def value
- Leaf(value) { this.value = value }
-}
-
-
-def buildTree() {
- new Tree(new Tree(new Leaf(1), new Leaf(2)), new Leaf(3))
-}
-
-
-buildTree()
------------------------------------------------------------------
-
-The creation of the tree is not very readable because of all
-those�`new`�keywords spread across the line. The Ruby approach wouldn\u2019t
-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:
-
-[source,groovy]
------------------------------------------
-@Newify([Tree, Leaf]) buildTree() {
- Tree(Tree(Leaf(1), Leaf(2)), Leaf(3))
-}
------------------------------------------
-
-You\u2019ll 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\u2019re 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:
-
-[source,groovy]
------------------------------------------
-@Immutable final class Coordinates {
- Double latitude, longitude
-}
-
-
-@Immutable final class Path {
- Coordinates[] coordinates
-}
-
-
-@Newify([Coordinates, Path])
-def build() {
- Path(
- Coordinates(48.824068, 2.531733),
- Coordinates(48.857840, 2.347212),
- Coordinates(48.858429, 2.342622)
- )
-}
-
-
-assert build().coordinates.size() == 3
------------------------------------------
-
-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)`.
-
-[[Groovy16releasenotes-CategoryandMixin]]
-=== @Category and @Mixin
-
-If you\u2019ve been using Groovy for a while, you\u2019re certainly familiar with
-the concept of Categories. It\u2019s 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\u2019s consider the example below:
-
-[source,groovy]
---------------------------------------------
-final class Distance {
- def number
- String toString() { "${number}m" }
-}
-
-
-class NumberCategory {
- static Distance getMeters(Number self) {
- new Distance(number: self)
- }
-}
-
-
-use(NumberCategory) {
- def dist = 300.meters
-
-
- assert dist instanceof Distance
- assert dist.toString() == "300m"
-}
---------------------------------------------
-
-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\u2019re going to add a�`getMeters()`�method to
-numbers, by actually decorating the�`Number`�type. By adding a getter to
-a number, you\u2019re able to reference it using the nice property syntax of
-Groovy. So instead of writing�`300.getMeters()`, you\u2019re 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\u2019s a first argument which represents the instance
-of the type we\u2019re 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:
-
-[source,groovy]
-----------------------------------
-@Category(Number)
-class NumberCategory {
- Distance getMeters() {
- new Distance(number: this)
- }
-}
-----------------------------------
-
-No need for declaring the methods�`static`, and the�`this`�you use here
-is actually the number on which the category will apply, it\u2019s 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\u2019ll 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:
-
-[source,groovy]
--------------------------------------------------
-@Category(Vehicle) class FlyingAbility {
- def fly() { "I'm the ${name} and I fly!" }
-}
-
-
-@Category(Vehicle) class DivingAbility {
- def dive() { "I'm the ${name} and I dive!" }
-}
-
-
-interface Vehicle {
- String getName()
-}
-
-
-@Mixin(DivingAbility)
-class Submarine implements Vehicle {
- String getName() { "Yellow Submarine" }
-}
-
-
-@Mixin(FlyingAbility)
-class Plane implements Vehicle {
- String getName() { "Concorde" }
-}
-
-
-@Mixin([DivingAbility, FlyingAbility])
-class JamesBondVehicle implements Vehicle {
- String getName() { "James Bond's vehicle" }
-}
-
-
-assert new Plane().fly() ==
- "I'm the Concorde and I fly!"
-assert new Submarine().dive() ==
- "I'm the Yellow Submarine and I dive!"
-
-
-assert new JamesBondVehicle().fly() ==
- "I'm the James Bond's vehicle and I fly!"
-assert new JamesBondVehicle().dive() ==
- "I'm the James Bond's vehicle and I dive!"
--------------------------------------------------
-
-You don\u2019t 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 \u2014 as we shall see in the
-metaprogramming enhancements further down in this article.
-
-[[Groovy16releasenotes-PackageScope]]
-=== @PackageScope
-
-Groovy\u2019s 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:
-
-[source,groovy]
----------------
-class Person {
- String name
-}
----------------
-
-Which is equivalent to this Java class:
-
-[source,groovy]
----------------------------------------------------
-public class Person {
- private String name;
- public String getName() { return name; }
- public void setName(name) { this.name = name; }
-}
----------------------------------------------------
-
-That said, this approach has one drawback in that you don\u2019t 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.
-
-[[Groovy16releasenotes-GrapetheGroovyAdaptableAdvancedPackagingEngine]]
-== Grape, the Groovy Adaptable / Advanced Packaging Engine
-
-To continue our overview of the AST transformations, we\u2019ll 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\u2019t even have to mess up with your
-classpath when running your script, just_grab_�the TagSoup library
-through Grape:
-
-[source,groovy]
-------------------------------------------------------------------------
-import org.ccil.cowan.tagsoup.Parser
-
-
-// find the PDF links in the Java 1.5.0 documentation
-@Grab(group='org.ccil.cowan.tagsoup', module='tagsoup', version='0.9.7')
-def getHtml() {
- def tagsoupParser = new Parser()
- def parser = new XmlParser(tagsoupParser)
- parser.parse("http://java.sun.com/j2se/1.5.0/download-pdf.html")
-}
-
-html.body.'**'.a.@href.grep(~/.*\.pdf/).each{ println it }
-------------------------------------------------------------------------
-
-For the pleasure of giving another example: let\u2019s use
-the�link:http://eclipse.org/jetty/[Jetty servlet container]�to
-expose�link:{DOCS_BASEURL}/html/documentation/template-engines.html[Groovy templates]�in
-a few lines of code:
-
-[source,groovy]
---------------------------------------------------------------------------------
-import org.mortbay.jetty.Server
-import org.mortbay.jetty.servlet.*
-import groovy.servlet.*
-
-
-@Grab(group = 'org.mortbay.jetty', module = 'jetty-embedded', version = '6.1.0')
-def runServer(duration) {
- def server = new Server(8080)
- def context = new Context(server, "/", Context.SESSIONS);
- context.resourceBase = "."
- context.addServlet(TemplateServlet, "*.gsp")
- server.start()
- sleep duration
- server.stop()
-}
-
-
-runServer(10000)
---------------------------------------------------------------------------------
-
-Grape will download Jetty and its dependencies on first launch of this
-script, and cache them. We\u2019re creating a new Jetty�`Server`�on port
-8080, then expose Groovy\u2019s�`TemplateServlet`�at the root of the context
-\u2014 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 \u2014 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�link:../grape.html[more information on Grape], please refer to the documentation.
-
-[[Groovy16releasenotes-Swingbuilderimprovements]]
-== Swing builder improvements
-
-To wrap up our overview of AST transformations, let\u2019s finish by speaking
-about two transformations very useful to Swing
-developers:`@Bindable`�and�`@Vetoable`. When creating Swing UIs, you\u2019re
-often interested in monitoring the changes of value of certain UI
-elements. For this purpose, the usual approach is to use
-JavaBeans�`PropertyChangeListener`s 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:
-
-[source,groovy]
-------------------------------------------------------------------------
-import com.googlecode.openbeans.PropertyChangeSupport;
-import com.googlecode.openbeans.PropertyChangeListener;
-
-
-public class MyBean {
- private String prop;
-
-
- PropertyChangeSupport pcs = new PropertyChangeSupport(this);
-
-
- public void addPropertyChangeListener(PropertyChangeListener l) {
- pcs.add(l);
- }
-
-
- public void removePropertyChangeListener(PropertyChangeListener l) {
- pcs.remove(l);
- }
-
-
- public String getProp() {
- return prop;
- }
-
-
- public void setProp(String prop) {
- pcs.firePropertyChanged("prop", this.prop, this.prop = prop);
- }
-
-}
-------------------------------------------------------------------------
-
-Fortunately, with Groovy and the�`@Bindable`�annotation, this code can
-be greatly simplified:
-
-[source,groovy]
--------------------------
-class MyBean {
- @Bindable String prop
-}
--------------------------
-
-Now pair that with Groovy\u2019s Swing builder new�`bind()`�method, define a
-text field and bind its value to a property of your data model:
-
-[source,groovy]
---------------------------------------------------------------------
-textField text: bind(source: myBeanInstance, sourceProperty: 'prop')
---------------------------------------------------------------------
-
-Or even:
-
-[source,groovy]
---------------------------------------------
-textField text: bind { myBeanInstance.prop }
---------------------------------------------
-
-The binding also works with simple expressions in the closure, for
-instance something like this is possible too:
-
-[source,groovy]
---------------------------------------------
-bean location: bind { pos.x + ', ' + pos.y }
---------------------------------------------
-
-You may also be interested in having a look
-at�link:{DOCS_BASEURL}/html/api/groovy/util/ObservableMap.html[ObservableMap]�and�link:{DOCS_BASEURL}/html/api/groovy/util/ObservableList.html[ObservableList],
-for a similar mechanism on maps and lists.
-
-Along with�`@Bindable`, there\u2019s also a�`@Vetoable`�transformation for
-when you need to be able to veto some property change. Let\u2019s consider
-a�`Trompetist`�class, where the performer\u2019s name is not allowed to
-contain the letter `z':
-
-[source,groovy]
----------------------------------------------------------------------------------------
-import com.googlecode.openbeans.*
-import groovy.beans.Vetoable
-
-
-class Trumpetist {
- @Vetoable String name
-}
-
-
-def me = new Trumpetist()
-me.vetoableChange = { PropertyChangeEvent pce ->
- if (pce.newValue.contains('z'))
- throw new PropertyVetoException("The letter 'z' is not allowed in a name", pce)
-}
-
-
-me.name = "Louis Armstrong"
-
-
-try {
- me.name = "Dizzy Gillespie"
- assert false: "You should not be able to set a name with letter 'z' in it."
-} catch (PropertyVetoException pve) {
- assert true
-}
----------------------------------------------------------------------------------------
-
-Looking at a more thorough Swing builder example with binding:
-
-[source,groovy]
-----------------------------------------------------------------------------
-import groovy.swing.SwingBuilder
-import groovy.beans.Bindable
-import static javax.swing.JFrame.EXIT_ON_CLOSE
-
-
-class TextModel {
- @Bindable String text
-}
-
-
-def textModel = new TextModel()
-
-
-SwingBuilder.build {
- frame( title: 'Binding Example (Groovy)', size: [240,100], show: true,
- locationRelativeTo: null, defaultCloseOperation: EXIT_ON_CLOSE ) {
- gridLayout cols: 1, rows: 2
- textField id: 'textField'
- bean textModel, text: bind{ textField.text }
- label text: bind{ textModel.text }
- }
-}
-----------------------------------------------------------------------------
-
-Running this script shows up the frame below with a text field and a
-lable below, and the label\u2019s text is bound on the text field\u2019s content.
-
-image:http://www.infoq.com/resource/articles/groovy-1-6/en/resources/bindable-example.png[image]
-
-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�link:http://griffon-framework.org/[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�link:http://griffon-framework.org/[Griffon].
-
-[[Groovy16releasenotes-Swingconsoleimprovements]]
-== Swing console improvements
-
-Swinging along the topic of UIs, the Swing console has also evolved:
-
-* The console can be run as an Applet (`groovy.ui.ConsoleApplet`).
-* Beyond syntax highlighting, the editor also supports code indentation.
-* Drag\u2019n droping a Groovy script over the text area will open the file.
-* You can modify the classpath with which the script in the console is
-being run, by adding a new JAR or a directory to the classpath as shown
-in the screenshot below.
-+
-+
-image:http://www.infoq.com/resource/articles/groovy-1-6/en/resources/sc-add-jar.png[image]
-+
-* A couple options have been added to the view menu item: for showing
-the script being run in the output area, and for visualizing the
-execution results.
-+
-+
-image:http://www.infoq.com/resource/articles/groovy-1-6/en/resources/sc-options.png[image]
-+
-* When an exception is thrown in your script, the lines of the
-stacktrace relative to your script are clickable, for easy navigation to
-the point where the error occurred.
-+
-+
-image:http://www.infoq.com/resource/articles/groovy-1-6/en/resources/sc-click-stack.png[image]
-+
-* Also, when your script contains compilation errors, the error messages
-are clickable too.
-+
-+
-image:http://www.infoq.com/resource/articles/groovy-1-6/en/resources/sc-click-comp-error.png[image]
-+
-
-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:
-
-image:http://www.infoq.com/resource/articles/groovy-1-6/en/resources/sc-without-visu.png[image]
-
-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`�\u2014 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`:
-
-[source,groovy]
----------------------------------------------------------
-import javax.swing.*
-
-transforms << { result ->
- if (result instanceof Map) {
- def table = new JTable(
- result.collect{ k, v -<
- [k, v?.inspect()] as Object[]
- } as Object[][],
- ['Key', 'Value'] as Object[])
- table.preferredViewportSize = table.preferredSize
- return new JScrollPane(table)
- }
-}
----------------------------------------------------------
-
-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\u2019re now able to
-visualize maps in a friendly and attractive fashion, as the screenshot
-below
-shows:image:http://www.infoq.com/resource/articles/groovy-1-6/en/resources/sc-with-visu.png[image]
-
-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.
-
-[[Groovy16releasenotes-Metaprogrammingenhancements]]
-== 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.
-
-[[Groovy16releasenotes-PerinstancemetaclassevenforPOJOs]]
-=== 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.
-
-[[Groovy16releasenotes-ExpandoMetaClassDSL]]
-=== ExpandoMetaClass DSL
-
-Initially developed under the�link:http://grails.org/[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�link:http://groovy.dzone.com/news/domain-specific-language-unit-[Unit
-manipulation DSL]�dealing with operator overloading:
-
-[source,groovy]
----------------------------------------------------------------------------------
-Number.metaClass.multiply = { Amount amount -> amount.times(delegate) }
-Number.metaClass.div = { Amount amount -> amount.inverse().times(delegate) }
-
-
-Amount.metaClass.div = { Number factor -> delegate.divide(factor) }
-Amount.metaClass.div = { Amount factor -> delegate.divide(factor) }
-Amount.metaClass.multiply = { Number factor -> delegate.times(factor) }
-Amount.metaClass.power = { Number factor -> delegate.pow(factor) }
-Amount.metaClass.negative = { -> delegate.opposite() }
----------------------------------------------------------------------------------
-
-The repetition, here, looks obvious. But with the ExpandoMetaClass DSL,
-we can streamline the code by regrouping the operators per type:
-
-[source,groovy]
-------------------------------------------------------------------
-Number.metaClass {
- multiply { Amount amount -> amount.times(delegate) }
- div { Amount amount -> amount.inverse().times(delegate) }
-}
-
-
-Amount.metaClass {
- div << { Number factor -> delegate.divide(factor) }
- div << { Amount factor -> delegate.divide(factor) }
- multiply { Number factor -> delegate.times(factor) }
- power { Number factor -> delegate.pow(factor) }
- negative { -> delegate.opposite() }
-}
-------------------------------------------------------------------
-
-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:
-
-[source,groovy]
----------------------------------------------------------
-// add a fqn() method to Class to get the fully
-// qualified name of the class (ie. simply Class#getName)
-Class.metaClass.static.fqn = { delegate.name }
-
-
-assert String.fqn() == "java.lang.String"
----------------------------------------------------------
-
-You can now do:
-
-[source,groovy]
------------------------------
-Class.metaClass {
- 'static' {
- fqn { delegate.name }
- }
-}
------------------------------
-
-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:
-
-[source,groovy]
-------------------------------------
-File.metaClass.getWordCount = {
- delegate.text.split(/\w/).size()
-}
-
-
-new File('myFile.txt').wordCount
-------------------------------------
-
-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 \u2014 each instance will have its property. Whenever a method
-is called on that car, this property is updated with a newer timestamp.
-
-[source,groovy]
-------------------------------------------------------------------------
-class Car {
- void turnOn() {}
- void drive() {}
- void turnOff() {}
-}
-
-
-Car.metaClass {
- lastAccessed = null
- invokeMethod = { String name, args ->
- def metaMethod = delegate.metaClass.getMetaMethod(name, args)
- if (metaMethod) {
- delegate.lastAccessed = new Date()
- metaMethod.doMethodInvoke(delegate, args)
- } else {
- throw new MissingMethodException(name, delegate.class, args)
- }
- }
-}
-
-
-
-def car = new Car()
-println "Last accessed: ${car.lastAccessed ?: 'Never'}"
-
-
-car.turnOn()
-println "Last accessed: ${car.lastAccessed ?: 'Never'}"
-
-
-car.drive()
-sleep 1000
-println "Last accessed: ${car.lastAccessed ?: 'Never'}"
-
-
-sleep 1000
-car.turnOff()
-println "Last accessed: ${car.lastAccessed ?: 'Never'}"
-------------------------------------------------------------------------
-
-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\u2019t exist.
-Later on, you can see by executing this script that�`lastAccessed`�is
-updated as soon as we call a method on our instance.
-
-[[Groovy16releasenotes-Runtimemixins]]
-=== Runtime mixins
-
-Last metaprogramming feature we\u2019ll 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\u2019t
-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\u2019t�_own_�James Bond\u2019s vehicle
-and give it some diving ability, we could use this mechanism:
-
-[source,groovy]
----------------------------------------------------
-// provided by a third-party
-interface Vehicle {
- String getName()
-}
-
-
-// provided by a third-party
-class JamesBondVehicle implements Vehicle {
- String getName() { "James Bond's vehicle" }
-}
-
-
-JamesBondVehicle.mixin DivingAbility, FlyingAbility
-
-
-assert new JamesBondVehicle().fly() ==
- "I'm the James Bond's vehicle and I fly!"
-assert new JamesBondVehicle().dive() ==
- "I'm the James Bond's vehicle and I dive!"
----------------------------------------------------
-
-One or more mixins can be passed as argument to the
-static�`mixin()`�method added by Groovy on�`Class`.
-
-[[Groovy16releasenotes-JSR-223GroovyScriptingEngine]]
-== 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\u2019t very developer friendly,
-requiring some additional work \u2014 the JAR wasn\u2019t even provided in the
-Groovy distribution. Thankfully, 1.6 comes with an implementation of
-the�`javax.script.*`�APIs.
-
-Below, you\u2019ll find an example evaluating Groovy expressions (the code is
-in Groovy, but it\u2019s straightforward to convert it back to Java):
-
-[source,groovy]
-----------------------------------------------
-import javax.script.*
-
-
-def manager = new ScriptEngineManager()
-def engine = manager.getEngineByName("groovy")
-
-
-assert engine.evaluate("2 + 3") == 5
-----------------------------------------------
-
-Please note that the�`javax.script.*`�APIs are available only on Java 6.
-
-[[Groovy16releasenotes-JMXBuilder]]
-== JMX Builder
-
-Originiating as an�link:http://code.google.com/p/groovy-jmx-builder/[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:
-
-* Domain Specific Language (DSL) for JMX API using Builder pattern
-* Simplified JMX API\u2019s programmability
-* Declaratively expose Java/Groovy objects as JMX managed MBeans
-* Support class-embedded or explicit descriptors
-* Inherent support for JMX\u2019s event model
-* Seamlessly create JMX event broadcasters
-* Attach event listeners as inline closures
-* Use Groovy\u2019s dynamic nature to easily react to JMX events
-notifications
-* Provides a flexible registration policy for MBean
-* No special interfaces or class path restrictions
-* Shields developer from complexity of JMX API
-* Exposes attribute, constructors, operations, parameters, and
-notifications
-* Simplifies the creation of connector servers and connector clients
-* Support for exporting JMX timers
-
-You can find�link:../jmx.html[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.
-
-[[Groovy16releasenotes-ImprovedOSGisupport]]
-== 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.
-
-[[Groovy16releasenotes-Summary]]
-== 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\u2019s scripting APIs, JMX management system, or OSGi\u2019s 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*.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/groovy-user-site/blob/de805f31/site/src/site/releasenotes/groovy-1.7.adoc
----------------------------------------------------------------------
diff --git a/site/src/site/releasenotes/groovy-1.7.adoc b/site/src/site/releasenotes/groovy-1.7.adoc
deleted file mode 100644
index cf401a0..0000000
--- a/site/src/site/releasenotes/groovy-1.7.adoc
+++ /dev/null
@@ -1,433 +0,0 @@
-[[Groovy17releasenotes-IDESupport]]
-== IDE Support
-
-Before diving directly into the new features in Groovy 1.7, please let
-me mention the great progress made in terms of IDE support for Groovy
-(and also for http://griffon-framework.org/[Griffon],
-http://gradle.org/[Gradle], https://gant.github.io/[Gant] or
-http://grails.org/[Grails]). All the major IDEs (Eclipse,
-http://www.jetbrains.com/idea/features/groovy_grails.html[IntelliJ
-IDEA], http://wiki.netbeans.org/Groovy[NetBeans]) provide an excellent
-level of support for the language. Initially, the Eclipse support was
-the one lacking the most, but thanks to the hard work of the
-SpringSource Eclipse team, we now have a great environment for
-developing mixed Java / Groovy applications with features like
-cross-language refactoring, Groovy-specific code completion, and more.
-
-New and Improved Eclipse pluginFor more information on the Eclipse
-support, please have a look at the Groovy Eclipse plugin home page, as
-well as the notes for the M1 release and M2 release.
-
-[[Groovy17releasenotes-Newfeatures]]
-== New features
-
-[[Groovy17releasenotes-AnonymousInnerClassesandNestedClasses]]
-=== Anonymous Inner Classes and Nested Classes
-
-Although oftentimes closures and maps coercion suffice, there are still
-areas where the lack of Anonymous Inner Classes (AIC) and Nested Classes
-(NC) can be problematic. That\u2019s why we decided to eventually implement
-AIC and NC in Groovy 1.7.
-
-Be CarefulThe implementation of AIC and NC follows the Java lead, but
-you should not take out the Java Language Spec and keep shaking the head
-about things that are different. The implementation done looks much like
-what we do for groovy.lang.Closure, with some benefits and some
-differences. Accessing private fields and methods for example can become
-a problem, but on the other hand local variables don\u2019t have to be final.
-
-[[Groovy17releasenotes-NestedStaticClasses]]
-==== Nested Static Classes
-
-Here\u2019s an example of Nested Static Classes:
-
-[source,groovy]
----------------------
-class A {
- static class B {}
-}
-
-new A.B()
----------------------
-
-The usage of static nested classes is the best supported one. If you
-absolutely need an inner class, you should make it a static one.
-
-[[Groovy17releasenotes-AnonymousInnerClasses]]
-==== Anonymous Inner Classes
-
-Some other examples, this time for Anonymous Inner Classes:
-
-[source,groovy]
---------------------------------
-boolean called = false
-
-Timer timer = new Timer()
-timer.schedule(new TimerTask() {
- void run() {
- called = true
- }
-}, 0)
-sleep 100
-
-assert called
---------------------------------
-
-More informationIf you want to learn a bit more about the cases which
-are currently supported in 1.7, you can have a look at one of our unit
-tests covering this new feature.
-
-[[Groovy17releasenotes-AccessingtheOuterContextfromaNestedClass]]
-==== Accessing the Outer Context from a Nested Class
-
-If you are in a nested class Y and the surrounding class is X, then you
-can access the variable v of X in Java by X.this.v. Groovy does not
-support this syntax.
-
-[[Groovy17releasenotes-CreatingInstancesofNon-StaticInnerClasses]]
-==== Creating Instances of Non-Static Inner Classes
-
-In Java you can do this:
-
-[source,java]
-----------------------------------
-public class Y {
- public class X {}
- public X foo() {
- return new X();
- }
- public static X createX(Y y) {
- return y.new X();
- }
-}
-----------------------------------
-
-It should be noted that the nested class X needs a reference to the
-outer class instance of Y. For this Java will create a constructor that
-takes Y as first parameter in X. This constructor is synthetic, so it
-won\u2019t appear in any code completion. +
- In case of new X(), like you have it in method foo(), then compiler
-will then create new X(this) instead. In case of createX the compiler
-will create new X(y). Groovy does not support this.
-
-Instead Groovy supports giving the instance in like the compiler would
-do it. That means the code above has to be rewritten as
-
-[source,groovy]
-----------------------------------
-public class Y {
- public class X {}
- public X foo() {
- return new X(this);
- }
- public static X createX(Y y) {
- return new X(y);
- }
-}
-----------------------------------
-
-CautionCaution though, Groovy supports calling methods with one
-parameter without giving an argument. The parameter will then have the
-value null. Basically the same rules apply to calling a constructor.
-There is a danger that you will write new X() instead of new X(this) for
-example. Since this might also be the regular way we have not yet found
-a good way to prevent this problem.
-
-[[Groovy17releasenotes-Annotations]]
-=== Annotations
-
-Groovy\u2019s support of annotations is identical to Java 5 annotations, but
-we felt that in some cases it would be interesting to be able to add
-annotations in other places than the usual places (types, fields,
-methods, parameters, etc.). For instance, in Java, it is impossible to
-add annotations on imports or packages. Groovy does go beyond and adds
-support for annotation on imports, packages and variable declarations.
-We\u2019ll take a look at the usage of those extended annotations on Grape.
-
-[[Groovy17releasenotes-Grape]]
-==== Grape
-
-The Grape dependency system lets you request dependencies in your
-scripts, without having to deal with downloading, packaging, or
-specifying the classpath yourself. To use Grape, we had to use the @Grab
-annotation to ``grab'' a dependency from a repository (Maven\u2019s central
-repository, for example). The problem was that annotation had to be
-attached to some allowed elements, ie. the places where annotations can
-be put in Java. Now, we can put annotations on imports:
-
-[source,groovy]
-------------------------------------------------------------------------------------
-@Grab(group='net.sf.json-lib', module='json-lib', version='2.3', classifier='jdk15')
-import net.sf.json.groovy.*
-
-assert new JsonSlurper().parseText(
- new JsonGroovyBuilder().json {
- book(title: "Groovy in Action", author:"Dierk K�nig et al")
- }.toString()
-).book.title == 'Groovy in Action'
-------------------------------------------------------------------------------------
-
-Another example with @Grab on variable declarations:
-
-[source,groovy]
---------------------------------------------------------------------------------------------------------
-@Grab('net.sf.json-lib:json-lib:2.3:jdk15')
-def builder = new net.sf.json.groovy.JsonGroovyBuilder()
-
-def books = builder.books {
- book(title: "Groovy in Action", author: "Dierk Koenig")
-}
-
-assert books.toString() == '''{"books":{"book":{"title":"Groovy in Action","author":"Dierk Koenig"}}}'''
---------------------------------------------------------------------------------------------------------
-
-RemarkPlease note on this one an improvement in the @Grab annotation: we
-provide a shorter version taking just a String as value parameter
-representing the dependency, in addition to the more verbose example in
-the previous example. You simply append the group, module, version and
-classifier together, joined by colons.
-
-A Grape *resolver* was added, so you can specify a remote location where
-grapes are downloaded from:
-
-[source,groovy]
-------------------------------------------------------------------
-@GrabResolver(name='restlet.org', root='http://maven.restlet.org')
-@Grab(group='org.restlet', module='org.restlet', version='1.1.6')
-import org.restlet.Restlet
-// ...
-------------------------------------------------------------------
-
-[[Groovy17releasenotes-PowerAsserts]]
-=== Power Asserts
-
-Groovy\u2019s ``assert'' keyword has sometimes been criticized as it\u2019s, in a
-way, limited, as it just checks that the expression it\u2019s being passed is
-true or false. Unlike with testing frameworks such as JUnit/TestNG and
-the various additional assertion utilities, where you get nicer and more
-descriptive messages, Groovy\u2019s assert would just tell you the expression
-was false, and would give the value of variables used in the expression,
-but nothing more. With Power Asserts, initially developed in the
-http://spockframework.org/[Spock Framework], the output of the assert is
-now much nicer and provides a visual representation of the value of each
-sub-expressions of the expression being asserted. For example:
-
-[source,groovy]
------------------------------------------------------
-assert new File('foo.bar') == new File('example.txt')
------------------------------------------------------
-
-Will yield:
-
-[source,groovy]
------------------------------------------------------
-Caught: Assertion failed:
-
-assert new File('foo.bar') == new File('example.txt')
- | | |
- foo.bar | example.txt
- false
------------------------------------------------------
-
-[[Groovy17releasenotes-AST]]
-=== AST
-
-With Groovy 1.6, we introduced AST Transformations, for letting
-developers do compile-time metaprogramming, by modifying the Abstract
-Syntax Tree before it is transformed into bytecode. In Groovy 1.6,
-several such transformations were added, especially ``local''
-transformations triggered by annotations (such as @Delegate, @Singleton,
-@Bindable and friends). However powerful this feature is, writing AST
-transformation has always been a bit tedious. Groovy 1.7 features two
-new features which should help simplify the work of AST transformation
-writers: an AST viewer and an AST builder.
-
-[[Groovy17releasenotes-ASTViewer]]
-==== AST Viewer
-
-The following screenshot shows a new window that can be launched from
-the Groovy Swing Console. You can visualize the AST of a script you\u2019re
-working on in the console: for instance, writing the code you\u2019d like to
-create in your AST transformation. The AST viewer greatly help with
-figuring out how Groovy builds its AST when compiling your Groovy
-code. +
- image:attachments/126320769/134184968.png[image]
-
-[[Groovy17releasenotes-ASTBuilder]]
-==== AST Builder
-
-Visualizing the AST is one thing, but we also need a mechanism to create
-and modify ASTs more easily. The introduction of the AST builder
-simplifies the authoring of AST transformations, by giving you three
-different approaches for working on the AST:
-
-* building from string
-* building from code
-* building from specification
-
-Before the AST builder, one had to create and instantiate manually all
-the various AST nodes. Let\u2019s see how those three forms help with this,
-for instance for creating a node representing a constant string.
-
-[[Groovy17releasenotes-Buildingfromstring]]
-===== Building from string
-
-[source,groovy]
------------------------------------------------------------------------
-List<ASTNode> nodes = new AstBuilder().buildFromString(''' "Hello" ''')
------------------------------------------------------------------------
-
-[[Groovy17releasenotes-Buildingfromcode]]
-===== Building from code
-
-[source,groovy]
-----------------------------------------------------------------
-List<ASTNode> nodes = new AstBuilder().buildFromCode { "Hello" }
-----------------------------------------------------------------
-
-[[Groovy17releasenotes-Buildingfromspecification]]
-====== Building from specification
-
-[source,groovy]
-------------------------------------------------------
-List<ASTNode> nodes = new AstBuilder().buildFromSpec {
- block {
- returnStatement {
- constant "Hello"
- }
- }
-}
-------------------------------------------------------
-
-For more informationPlease have a look at the documentation on the AST
-Builder. You\u2019ll discover the advantages and inconveniences of the
-various forms, and why all three are needed depending on what you want
-to achieve with the AST.
-
-[[Groovy17releasenotes-Otherminorenhancements]]
-Other minor enhancements
-------------------------
-
-[[Groovy17releasenotes-AbilitytocustomizetheGroovyTruth]]
-=== Ability to customize the Groovy Truth
-
-In Groovy, booleans aren\u2019t the sole things which can be evaluated to
-true or false, but for instance, null, empty strings or collections are
-evaluated to false or true if of length > 0 or non-empty. This notion of
-'truth' was coined 'Groovy Truth' in the
-http://www.manning.com/koenig/[Groovy in Action] book. With Groovy
-Truth, instead of doing frequent null checks, you could simply write:
-
-[source,groovy]
---------------------------------------------------------------
-def string = "more than one character"
-if (string) { println "the String is neither null nor empty" }
---------------------------------------------------------------
-
-Up until Groovy 1.7, only a small set of classes had a certain meaning
-with regards to how they were coerced to a boolean value, but now it is
-possible to provide a method for coercion to boolean in your own
-classes. For example, the following Predicate class offers the ability
-to coerce Predicate instances to true or false, thanks to the
-implementation of the boolean asBoolean() method:
-
-[source,groovy]
------------------------------------
-class Predicate {
- boolean value
- boolean asBoolean() { value }
-}
-
-assert new Predicate(value: true)
-assert !new Predicate(value: false)
------------------------------------
-
-Is is also possible to use categories or ExpandoMetaClass to inject an
-asBoolean() method, or to override an existing one (even one on the
-small set of classes with special Groovy truth behavior).
-
-[[Groovy17releasenotes-Dependencyupgrades]]
-=== Dependency upgrades
-
-Some of the dependencies of Groovy have been upgraded to newer versions.
-
-For instance, Groovy now uses the latest ASM version, which is
-``invokedynamic''-ready. So as we progress towards the inclusion of
-JSR-292 / invokedynamic, we\u2019ll be ready and be using the latest version
-of ASM. We also use the latest version of Ivy which is used by the Grape
-dependency module.
-
-[[Groovy17releasenotes-RewriteoftheGroovyScriptEngine]]
-=== Rewrite of the GroovyScriptEngine
-
-The GroovyScriptEngine (which is also used by Groovlets) has been
-rewritten to solve various dependency issues it was suffering from, and
-the outcome of this is that it should also now be much faster overall.
-
-The new logic uses additional phase operations to track dependencies. As
-a result the error-prone class loader technique to track them is gone
-now. These operations ensure that every script file will be tracked, its
-dependencies recorded during compilation and all transitive dependencies
-will be calculated. And only scripts will be recorded as dependency, no
-classes. The new GroovyScriptEngine also uses only one compilation
-``process'' for script compilation which solves the problem of circular
-or mutual dependencies, that caused stack overflows in the past. As a
-result the new engine can reliably handle dependencies and should be
-much faster.�
-
-[[Groovy17releasenotes-Groovyconsolepreferences]]
-=== Groovy console preferences
-
-A small annoyance, especially for developers using big LCD screens: the
-Groovy Console didn\u2019t remember preferences of position of the separator
-between the coding area and output view, or the font size being used.
-This is now fixed, as the console remembers such settings. You won\u2019t
-need anymore to adjust the console to your liking each time you run it,
-it should now have some more brain cells to remember your preferences.
-
-[[Groovy17releasenotes-NewoutputwindowfortheGroovyconsole]]
-=== New output window for the Groovy console
-
-There is a new visualization option for the results of the execution of
-your scripts in your Groovy Console. Instead of displaying the results
-in the bottom output pane, it\u2019s now possible to use an external window
-for viewing those results. Run your script with CTRL-R or CMD-R, you
-will see something like the following screenshot. You can then dismiss
-the window by hitting Escape, CTRL-W (CMD-W on Macs) or Enter.
-image:attachments/126320769/135528463.png[image] +
- You will also notice the addition of line numbers in the gutter of the
-editor area.
-
-[[Groovy17releasenotes-SQLbatchupdatesandtransactions]]
-=== SQL batch updates and transactions
-
-[[Groovy17releasenotes-Batchupdates]]
-==== Batch updates
-
-The Groovy Sql class now features batch updates, thanks to its new
-withBatch() method, taking a closure and a statement instance:
-
-[source,groovy]
-----------------------------------------------------------------
-sql.withBatch { stmt ->
- ["Paul", "Jochen", "Guillaume"].each { name ->
- stmt.addBatch "insert into PERSON (name) values ($name)"
- }
-}
-----------------------------------------------------------------
-
-[[Groovy17releasenotes-Transactions]]
-==== Transactions
-
-Similarly, there\u2019s a withTransaction() method added to Sql, which works
-also with datasets:
-
-[source,groovy]
------------------------------------
-def persons = sql.dataSet("person")
-sql.withTransaction {
- persons.add name: "Paul"
- persons.add name: "Jochen"
- persons.add name: "Guillaume"
-}
------------------------------------