Message-ID: <1108206492.227.1429327672032.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_226_1683221889.1429327672031" ------=_Part_226_1683221889.1429327672031 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Groovy 2.3 is the new major r=
elease of Groovy, featuring official support for running Gr=
oovy on JDK 8,
traits, new and i=
mproved AST transformations like @TailRecursive, @Builder and @Sortable, a new NIO2=
module with Path suppor=
t, lightening fast JSON parsing and building, closure parameter typ=
e inference, a new markup template engine, Groovysh and GroovyConsole ease of use improvements, a new GroovyAssert =
test utility, more @BaseScript class capabilities, and more.
This is the first version of Groovy t=
o be officially compatible with JDK 8.
JDK 8 and its interface default methods introduced some incompatibilities = with a few methods of the Groovy Development Kit, so we had to adapt to the= situation, introducing minor breaking changes for the affected methods and= their outcome.
Note that we=E2=80=99r= e not planning to backport the changes to older versions of Groovy, so if y= ou want to run Groovy on JDK 8, you=E2=80=99ll have to upgrade to the shini= est version of Groovy!
Groovy 2.3 doesn=E2=80=99t support th= e new syntax constructs offered by Java 8 (such as lambdas, method referenc= es, default methods in interfaces, etc), but you can very well already use the new APIs offered by J= DK 8, a= nd even use Groovy closur= es in lieu of Java 8 lambdas.
For reference, here are a couple of e= xamples which use Java 8 streams, for iterating over a stream of ints, or o= ver the lines of a file:
In particular, in the two statements = above, notice that we replaced Java 8 lambdas with Groovy closures, as Groo= vy provides a closure coercion mechanism which transforms a Groovy closure = into a functional interface =E2=80=94 unlike Java, Groovy also provides tha= t coercion mechanism for abstract classes containing a single abstract meth= od.
In future versions of Groovy, certain= Java 8 syntax constructs, or particular Groovy methods decorating JDK 8 AP= Is might be added.
A major highlight for Groovy 2.3 is t=
he introduction of the co=
ncept of traits.<=
span style=3D"color: rgb(0,0,0);">
Traits are reusable components of behavior that your clas= ses can implement, and are an additional Object-Oriented concept alongside = classes and interfaces.
Below, we create a trait with a concr= ete method fly() which returns a String.
Then we create a class, Bird, that im= plements that trait, and instantiate it:
We can check that the Bird instance d= oes have the new fly() method mixed-in:
Groovy traits are stateful (unlike Ja= va 8 interface default methods).<= br class=3D"kix-line-break" />
A trait can have Groovy properties li= ke plain classes:
This time, the Bird class implements = that Named trait:
We can instantiate the Bird with the = named-argument constructor shortcut provided by Groovy:
We assert that the instantiated Bird = does have the name property added to it:
They allow the composition of behavio= r without going into the =E2=80=9Cdiamond inheritance=E2=80=9D problem allo= wing you to decide which behavior prevails upon conflict, either by convent= ion (last trait declared wins) or by explicitly overriding the conflicting = method:
Above, the surf() method from WebSurf= er wins, as it=E2=80=99s the last declared trait, but you can reverse the t= rait implementation order if you want kite to be returned. If you want to b= e more explicit, your Hipster class can override the surf() method itself, = and call WebSurfer.super.foo() or KiteSurfer.super.foo() or do something en= tirely different.
Traits support inheritance, thus a tr= ait can extend another trait or implement an interface, as shown below:
Traits are compatible with static type = checking and compilation, as well as our usual dynamic behavior. Trait mixe= d-in methods are actually =E2=80=9Creal=E2=80=9D methods (ie. visible from = Java as well) and not just dynamic. Note however, that not all existing AST= transformations are compatible with traits.
Traits can also be implemented at runtime with =E2=80=9Cas=E2=80=9D = or with =E2=80=9CwithTraits=E2=80=9D if you just want to add behavior of a = trait to an object you=E2=80=99re instantiating, without having to create a= n intermediary artificial class just for that purpose (also called per-inst= ance traits):
You can find more information on traits in the exhaustive <= a href=3D"http://beta.groovy-lang.org/docs/groovy-2.3.0/html/documentation/= core-traits.html" class=3D"external-link" rel=3D"nofollow">trait documentation.
@TailRecursive on methods adds tail r= ecursion to methods which are recursive and call themselves at the last ope= ration of the method body, which helps avoid blowing up the stack with the = recursive calls (GROOVY-6570).
Here=E2=80=99s a slightly rewritten f= actorial implementation, that is friendly to tail-call transformation:
Recent Java APIs have adopted the bui= lder pattern (not to be confused with Groovy=E2=80=99s builders) to instant= iate complex objects, without requiring to multiply the number of construct= ors with variants taking various combination of parameters. Groovy 2.3 intr= oduces a @Builder transformation to automate the creation of such builder A= PIs (GROOVY-6484).
The @Builder transformation offers di= fferent implementation strategies that you can choose from:
a simple strategy for creating chained setters
an external strategy where you annotate an explicit builder cl= ass while leaving some buildee class being built untouched
a default strategy which creates a nested helper class for ins= tance creation
and an initializer strategy which creates a nested helper clas= s for instance creation which when used with @CompileStatic allows type-saf= e object creation
Here=E2=80=99s an example with the de= fault strategy:
You can have a look at the @Bui= lder documentation for the ot= her builder variants.
@Sortable on classes implements compa= rison methods for you (through implementing the Comparable interface), acco= rding to the declaration order of your properties (GROO= VY-6649).
For the following Person class, its i= nstances will be sorted by last name, then by first name, and by age, in th= at order:
Additionally, you can define included= / excluded fields, access individual field comparators with methods like c= omparatorByFirst().
More details on the <= span style=3D"color: rgb(17,85,204);text-decoration: underline;">@Sortable = documentation page.
With @SourceURI, you can annotate a j= ava.net.URI or even a java.lang.String script variable or class field so th= at the variable or field are injected the URI of the Groovy file.
If you evaluate or compile a Groovy s= cript or class, the variable or field will contain a data URI, for example,= for the following example:
The src variable will contain the fol= lowing data URI:
If you save the script in a file call= ed sourceuri.groovy in /tmp, and run that script with the groovy command, y= ou=E2=80=99ll see an absolute File path printed:
As I mentioned above, you can also wr=
ite @SourceURI URI src
@Delegate supports includeTypes and e= xcludeTypes attributes to give you fine-grained control over which methods = to include or exclude from delegation. Rather than just matching on name, t= his option matches on the name and parameter types expressed in an interfac= e type (GROOVY-6329).
@BaseScript is a fairly recent addition in =
Groovy, and it allowed to annotate a variable in your script to instruct th=
e compiler to use a particular base script class for this script. Now we ha=
ve another notation which is nicer as you can annotate an import or a packa=
ge (GROOVY-6592) to indicate that base script class:
Additionally, base script classes can= now use any abstract method for the script body. This means that you can i= mplement the run() method to implement specific behavior like setup and tea= r down in tests (GROOVY-6585 and GROOVY-6615).
Given the following custom base scrip= t class, where we implement the default run() method, we also create a new = abstract method called internalRun():
We can then have the script below tra= nsparently implement the internalRun() method instead of the usual run() on= e:
On JDK 7 and beyond, you can benefit =
from the same methods as the ones of File but for the new NIO2 class Path.<=
See GROOVY-6377 and the pull request for some f= urther hints of the new methods.
You=E2=80=99ll find familiar methods = of the Groovy GDK on File also available on Path like these ones:
Various minor performance improvements across the board= , for static compilation, the = =E2=80=9Cinvoke dynamic=E2=80=9D backend, as well as =E2=80=9Cnormal=E2=80= =9D dynamic Groovy, have been worked on.
Groovy JSON support has been refactor=
ed and tailored towards performance, making Groovy 2.3=E2=80=99s JSON suppo=
rt usually faster than al=
l the JSON libraries
Rick Hightower and Andrey Bleschestov= covered the performance gains, both in parsing and seralization, in a benchmarks on Rick= =E2=80=99s blog and on Andrey=E2=80=99s JSON benchmark project on Github. The results are impressive, as the <= strong>parsing is generally roughly 2x t= o 4x faster with Groovy= =E2=80=99s new parsers compared to existing libraries, and ~21x faster than pre-Gro= ovy 2.3 parsing. On the = serialization front, Groovy=E2=80=99s new serialization is also ~17x faster than before, and at the same level as competing = libraries.
Beside the performance improvements o= f the JSON module, other updates have taken place.
With JsonSlurper, you=E2=80=99ll be able to set different parser types depending on the kind of input you wish to parse,= particularly if you know the size of the payload you expect to parse, or w= hether you want a more tolerant parser which accepts elements like comments= which are not normally supported by the JSON specification.
Here=E2=80=99s an example showing how= to parse a non-conformant JSON payload:
We closed a gap which forced you to t=
ype your closure parameters to get correct type inference with static type =
checking or static compilation enabled. In situations like the following, y=
ou would have to explicitly give the type of the parameter, but it=E2=80=99=
s no longer required:
In the signature of your methods taki=
ng closures as arguments, you=E2=80=99ll also be able to annotate the closu=
re parameter with @ClosureParams=
to give additional hints to the type checker to infer the type of the para=
meters passed to your closure.
You can= also find more about this in Cédric=E2=80=99s blog post on <= a href=3D"http://melix.github.io/blog/2014/01/closure_param_inference.html"= class=3D"external-link" rel=3D"nofollow">closure parameter type inference.
Groovy now has an additional template=
engine, in the form of the Markup template engine, which gives you a very =
fast template engine (thanks to static compilation), based on the familiar =
Markup builder approach and notation, but also offering formatting options =
(indentation, escaping), internationalization, includes, as well as proposi=
ng type checked templates and models.
= More details about the new Markup template engine in the documentation, as well as in Cédric=E2=80=99s = blog, if you want to lea= rn more about the =E2=80=9Cbehind the scenes=E2=80=9D stories!
To illustrate the basic usage, consid= er you have the following template:
And have the following model:<= /p>
You would generate the following XML = (or HTML) output:
By doing the following:
You have useful methods available to = your templates, like for including other templates:
And if you want to have your model be= type checked, you can either define the model types inside the template li= ke so:
Or by using the dedicated template cr= eation method:
Note that this template engine is sup= er fast as it=E2=80=99s statically compiled.
The venerable GroovyTestCase (JUnit 3 based approach) has often been used as =
a base class for your test classes =E2=80=94 unless you=E2=80=99ve been usi=
ng the Spock testing framework, of course. One of the drawback of this class is that your test cl=
asses can=E2=80=99t extend your own classes, but must derive from GroovyTes=
tCase to benefit from the additional assertion methods.
In earlier versions of Groovy we introduced the JUn= it 4-friendly GroovyAssert, which is a convenient class offering the usual = assertion methods of GroovyTestCase, but in the form of static methods that= you can static import in your test class. In Groovy 2.3 we=E2=80=99ve enri= ched GroovyAssert with additional features. There should be no reason to mo= ve on from JUnit 3 if you haven=E2=80=99t already done so. We didn=E2=80=99= t include all of the myriad of assertEquals methods from GroovyTestCase as = they are typically less useful than Groovy=E2=80=99s built-in power assert,= but it provides some handy shouldFail() and assertScript() methods (GROOVY-6588).= span>
For instance, if you want to leverage= the shouldFail(String) and assertScript(String) methods, you can do so as = follows:
import static groovy.test.GroovyAsser= t.shouldFail
ConfigSlurper has previously supporte= d a single =E2=80=9Cenvironments=E2=80=9D non-configurational conditional b= lock, but you couldn=E2=80=99t define your own. With Groovy 2.3 you can als= o create your own such blocks. For instance if you wanted to support =E2=80= =9Cflavors=E2=80=9D like OS variants (GROOVY-6383).
Concretely, instead of the familiar e= nvironments / production blocks in Grails, let=E2=80=99s register a flavors= / prod pair:
In addition, the isSet() / hasSet() c= ombo methods (GROOVY-4639) have been added so you can double check if a given node o= f your configuration has been defined. Before, whether the node wasn=E2=80= =99t defined or containing null, you couldn=E2=80=99t differentiate either = case easily.
Along with a slightly reduced startup=
time, Groovysh has seen new improvements in its code-completion capabiliti=
Commands are now prefixed with ":" (GROOVY=
It is now possible to configure the f=
ont used by the console (GROOVY-6303, although without a UI dialog yet), and also t=
o be able to run a selected snippet of code reusing the imports defined in =
your script making it easier to just run quick snippets of your script. The=
ability to comment or uncomment selecte=
d code by pressing "Ctrl +" was added with GROOVY-6459 .
We are still working on the brand new documentation for Groovy (in Asciidoc(tor) format), so you ca=
n already have a glimpse at what=E2=80=99s already covered or not.
We=E2=80=99re looking forward to your help for= fleshing out the various TBD (To Be Done) sections of the documentation, a= s it=E2=80=99s a gigantic task to re-document each and every aspect of the = language and its libraries! So please shout if you want to <= span style=3D"color: rgb(0,0,0);">contribute to the new documentation! All help is warmly welcome!<= /span>
GroovyDoc has been updated with a new=
fresh and modern skin that will be part of the future visual identity of t=
he Groovy website. Those style updates are also available by default for yo=
ur own usage of GroovyDoc, making your own documentation nicer on the eye.<=
You can have a look at the GroovyDoc documentation for Groovy 2.3.0
We also took the opportunity to apply=
the same stylesheet to our =E2=80=9CDocGenerator=E2=80=9D tool which is re=
sponsible for the generation of the GDK documentation, showing the methods =
the Groovy library adds on top of the JDK classes.
Please also have a look at the new restyled GDK documentation.
The following dependencies have been = upgraded:
GPars 1.2 for all your concurrency, asynchron= ous or parallelism needs:
improvements in the dataflow area, such as lazy tasks and easy= fork-and-join on Promises
actors and dataflow operators now use the Groovy @DelegatesTo = annotation to allow for statically compiled bodies
GPars timers and thread-locals have been made more friendly to= wards managed environments and the GParsConfig class now allows GPars to be= completely shutdown
Gradle 1.10 for building Groovy
ASM 5.0.1 library for generating our bytecode= (also needed for our JDK 8 support)
JLine 2.11 and JANSI 1.11 library for Groovysh
Ant 1.9.3 for the Ant builder
TestNG 6.8.8 for the TestNG module=
Groovy 2.3.0 introduces a limited lis= t of breaking changes.
First of all, Groovy 2.3.0 now requires JDK 6<= span style=3D"color: rgb(0,0,0);"> as its minimal JDK requirement. Some par= ts of Groovy 2.3.0 might still run under JDK 5 but no testing has been done= on that platform and some parts are known not to work. We encourage everyo= ne to move to at least JDK 6.
In Groovy 2.3.0, we reworked = our implementation of generics handling. Although we don=E2=80=99t= know of any particular breakage so far, the static type checker might repo= rt new errors as it can be stricter than before. If ever you encounter such= new errors in this area, please report them as soon as you encounter them.=
With the introduction of "traits= " in Groovy 2.3, the "trait" keyword is an addition to the l= ist of keyword of the languages, with the consequence that variable= s or fields that would use "trait" as name with yield a compilati= on error. So you would have to change the name of your variable an= d recompile your code.
A few updates have been made to the <= strong>XML support around whitespace handling, and text node handling:
With the new default methods on inter=
faces in JDK 8, there was particularly one, a =
(Comparable) method, which
conflicted with one of the GDK, so we had to remove ours to =
stay compliant with JDK 8.
We fixed a race c= ondition in AbstractHttpServler#applyResourceNameMatcher which incurred a small change in behavior. This= feature is seldomly used and doesn=E2=80=99t seem to have impacted users o= f the Groovy servlet machinery so far.
You can look at the list of the breaking changes from our JIRA<= span style=3D"color: rgb(0,0,0);"> issue tracker.