| Groovy, the Java-like dynamic language for |
| the JVM, matures over time like good wines. After the successful release |
| of Groovy 1.0 in January 2007, the next major milestone with the 1.5 |
| label already hits the shelves. With it, come several interesting |
| novelties that we will examine in this article. The major addition to |
| the language is the support of Java 5 features with annotations, |
| generics and enums, making Groovy *the sole alternative dynamic language |
| for the JVM fully supporting frameworks like Spring, Hibernate, JPA*, |
| Google Guice, or TestNG. Apart from the new Java 5 features, a few |
| syntax enhancements find their way in the language, as well as a more |
| powerful dynamic behavior customization, a Swing UI builder on steroids, |
| and improved tooling support. |
| |
| [[Groovy15releasenotes-AgroovierGroovyandwhyitmatters]] |
| == A groovier Groovy and why it matters |
| |
| Groovy’s key selling point has always been its *seamless integration |
| with Java*. You can mix and match Groovy and Java classes together in |
| very easy ways: You may have a Groovy class extending a Java class |
| implementing a Groovy interface, and vice versa. Most of the other |
| alternative JVM languages unfortunately won’t let you seamlessly |
| interchange classes of two different languages. So if you want to use |
| the best language for the job without compromising your nice class |
| hierarchy, you won’t have many options to choose from, and Groovy gives |
| you all the freedom for integrating both languages in the most |
| transparent way. |
| |
| Groovy shares the same libraries, the same object model, the same |
| threading model, and the same security model as Java. In a way, you can |
| consider Groovy as an implementation detail of your Java |
| project, *without having to bear problematic impedance mismatch issues*. |
| |
| Groovy is Java, and Groovy makes Java groovier. Compared with other |
| languages, Groovy is certainly the language that provides the *flattest |
| learning curve to Java developers*, thanks to a very similar syntax. |
| |
| This is even more important to keep in mind that Groovy generates normal |
| Java bytecode and uses the usual JDK libraries, so you won’t need to |
| learn whole new APIs or have complex integration mechanisms: out of the |
| box, Groovy and Java are interchangeable. The added benefit is that you |
| can *protect the investment*you made in Java *skills for your |
| developers*, or in *costly application servers*, or third party |
| or *home-grown libraries*, as you can reuse all of them without a |
| problem from Groovy. |
| |
| Speaking of calling into JDK, third party, or in-house libraries, |
| alternative languages which don’t support strong typing, can’t always |
| call all Java methods because of the fact they can’t choose a certain |
| polymorphic variation of the same method. When choosing an alternative |
| language to improve your productivity or make your code more readable, |
| if you need to call other Java classes, you will have to be very careful |
| to the choice of language you will make, as you may encounter some road |
| blocks along the way. |
| |
| These days, all major Enterprise frameworks require the use of features |
| like annotations, enums or generics, to be leveraged at their fullest |
| extent. Fortunately, with Groovy 1.5, developers can benefit from the |
| support of all these Java 5 features in their projects. Let’s see how |
| annotations, enums and generics can be used from Groovy. |
| |
| [[Groovy15releasenotes-Java5additions]] |
| == Java 5 additions |
| |
| The Groovy compiler always generates Java bytecode which is compatible |
| with older Java VMs, but relies on JDK 1.4 for the core libraries it is |
| using. However, for certain of these Java 5 additions, using Java 5 |
| bytecode was required, so that, for example, the generated classes may |
| contain the bytecode information representing annotations with runtime |
| retention policy. So although Groovy 1.5 can run on JDK 1.4, certain of |
| these features will only be usable on JDK 5 - when this is the case, it |
| will be mentioned in this article. |
| |
| [[Groovy15releasenotes-Variablearguments]] |
| === Variable arguments |
| |
| In Java 5, the ellipsis notation was created to denote methods with |
| variable length arguments. With those little triple dots, Java lets |
| users put as many parameters of the same type at the end of a method - |
| actually, the vararg parameter is just an array of elements of that |
| type. Varargs were already present in Groovy 1.0 - and still work with a |
| JDK 1.4 runtime, but it is good to show how you can use them. Basically, |
| whenever the last argument of a method is an array of objects, or a |
| parameter declaration with a triple dot, you can pass multiple |
| parameters to this method. |
| |
| A first example will show the usage of varargs in Groovy with the |
| ellipsis: |
| |
| [source,groovy] |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| int sum(int... someInts) { |
| def total = 0 |
| for (int i = 0; i < someInts.size(); i++) total += someInts[i] |
| return total |
| } |
| assert sum(1) == 1 |
| assert sum(1, 2) == 3 |
| assert sum(1, 2, 3) == 6 |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| The assertions used in this example show how we can pass as many ints as |
| desired. It is also interesting to see that, for more syntax |
| compatibility with Java, the classical for loop has been added into |
| Groovy - despite the presence of the groovier version with the in |
| keyword that can also transparently iterate over various array or |
| collection types. |
| |
| Note that it is possible to have varargs support even with an array as |
| last parameter by declaring the method as follows: |
| |
| [source,groovy] |
| --------------------------------- |
| int sum(int[] someInts) { /* */ } |
| --------------------------------- |
| |
| This snippet is really trivial, and there are obviously more expressive |
| ways of calculating a sum. For instance, if you have a list of numbers, |
| you can sum all of them in a single line of code: |
| |
| [source,groovy] |
| --------------------------- |
| assert [1, 2, 3].sum() == 6 |
| --------------------------- |
| |
| Varargs in Groovy don’t require JDK 5 as the underlying Java runtime, |
| unlike annotations that we are now going to look at in the following |
| section. |
| |
| [[Groovy15releasenotes-Annotations]] |
| === Annotations |
| |
| As shown in |
| the http://docs.jboss.com/seam/1.3.0.ALPHA/reference/en/html/ch10.html[documentation |
| of JBoss Seam] which supports Groovy for writing its entities, |
| controllers and components, annotations like *@Entity, @Id, |
| @Override* and others can be used to decorate your beans: |
| |
| [source,groovy] |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| @Entity |
| @Name("hotel") |
| class Hotel implements Serializable { |
| @Id @GeneratedValue Long id |
| @Length(max=50) @NotNull String name |
| @Length(max=100) @NotNull String address |
| @Length(max=40) @NotNull String city |
| @Length(min=2, max=10) @NotNull String state |
| @Length(min=4, max=6) @NotNull String zip |
| @Length(min=2, max=40) @NotNull String country |
| @Column(precision=6, scale=2) BigDecimal price |
| @Override |
| String toString() { |
| return "Hotel(${name}, ${address}, ${city}, ${zip})" |
| } |
| } |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| The Hotel entity is marked with the @Entity annotation, and it’s given a |
| name through @Name. Different parameters can be passed to your |
| annotations like in the @Length annotation constraint where different |
| upper and lower bound can be set for validation purpose. You can also |
| notice *Groovy properties* in action: Where are all the getters and |
| setters? Where are the public or private modifiers? You don’t have to |
| wait for Java 7 or 8 to get properties! By convention, defining a |
| property is as simple as String country: a private country field will be |
| auto-generated, as well as a public getter and setter. *Your code |
| becomes naturally more concise and readable*. |
| |
| Annotations can be used on classes, fields, methods and method |
| parameters, like in Java. There are, however, two gotchas to be aware |
| of. Firstly, you can use annotations in Groovy, but you cannot yet |
| define them - however, it will be possible in an upcoming version of |
| Groovy. Secondly, although the syntax is almost 100% the same as in |
| Java, there is a little difference when an array of values is passed in |
| parameter of the annotation: instead of curly braces to surround the |
| elements, Groovy requires the use of square brackets to offer a more |
| homogeneous syntax - since Groovy lists and arrays use square brackets |
| to surround their elements as well. |
| |
| With annotations in Groovy 1.5, you can easily define your JPA or |
| Hibernate annotated beans |
| in Groovy, add an `@Transactional` annotation on your Spring services, |
| test your Swing UI with TestNG and Fest |
| (http://www.jroller.com/aalmiray/entry/testing_groovy_uis_with_fest). |
| All the useful and powerful enterprise frameworks leveraging annotations |
| can be used from your Groovy-powered projects. |
| |
| [[Groovy15releasenotes-Enums]] |
| === Enums |
| |
| Whenever you need a fixed set of constants of a same type, Enums come in |
| handy. Say you need a clean way to define constants for days without |
| resorting to using integer constants? Then Enums are your friend. The |
| following snippet shows how to define the days of the week: |
| |
| [source,groovy] |
| ---------------------------------------------------------------------------------- |
| enum Day { SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY } |
| ---------------------------------------------------------------------------------- |
| |
| Once you have defined your enum, you can use it as in Java with the |
| usual notation *Day.MONDAY* and you can spice up your switch / case |
| statements with it as well: |
| |
| [source,groovy] |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| def today = Day.SATURDAY |
| switch (today) { |
| // Saturday or Sunday |
| case [Day.SATURDAY, Day.SUNDAY]: println "Weekends are cool" |
| break |
| // a day between Monday and Friday |
| case Day.MONDAY..Day.FRIDAY: println "Boring work day" |
| break |
| default: println "Are you sure this is a valid day?" |
| } |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| Notice that Groovy’s switch is a bit more powerful than C-like languages |
| switches in that it is possible to use any kind of object in the switch |
| and case. Instead of stacking up seven different case block with each |
| enumerated value, you can regroup them in lists or ranges: whenever the |
| value is in the list or the range, the case will be true and its |
| associated instructions will be executed. |
| |
| A more complex example inspired by the Java tutorial takes a more |
| astronomical perspective on enums, and shows how your enums can have |
| properties, constructors and methods: |
| |
| [source,groovy] |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| enum Planet { |
| MERCURY (3.303e+23, 2.4397e6), |
| VENUS (4.869e+24, 6.0518e6), |
| EARTH (5.976e+24, 6.37814e6), |
| MARS (6.421e+23, 3.3972e6), |
| JUPITER (1.9e+27, 7.1492e7), |
| SATURN (5.688e+26, 6.0268e7), |
| URANUS (8.686e+25, 2.5559e7), |
| NEPTUNE (1.024e+26, 2.4746e7) |
| double mass |
| double radius |
| Planet(double mass, double radius) { |
| this.mass = mass; |
| this.radius = radius; |
| } |
| void printMe() { |
| println "${name()} has a mass of ${mass} " + |
| "and a radius of ${radius}" |
| } |
| } |
| Planet.EARTH.printMe() |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| Like annotations, enums in Groovy require a JDK 5+ to run on, as Java 5 |
| bytecode is generated. |
| |
| [[Groovy15releasenotes-Staticimports]] |
| === Static imports |
| |
| In our previous examples of enums, we always had to prefix the |
| enumerated value with its parent enum class, but thanks to static |
| imports (which work even on a JDK 1.4 runtime) we can save some |
| characters by dropping the Planet prefix: |
| |
| [source,groovy] |
| -------------------------------------- |
| import static Planet.*SATURN.printMe() |
| -------------------------------------- |
| |
| No more Planet prefix. But of course, static imports aren’t only |
| available for enums, but also work for other classes and static fields. |
| What about doing some math? |
| |
| [source,groovy] |
| ------------------------------------------------------------------- |
| import static java.lang.Math.*assert sin(PI / 6) + cos(PI / 3) == 1 |
| ------------------------------------------------------------------- |
| |
| Both the static methods of *java.lang.Math* and its static constants |
| were statically imported to make the expression more concise. But if the |
| abbreviations of sine and cosine are not readable for you, you can use |
| aliasing in Groovy with the as keyword: |
| |
| [source,groovy] |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| import static java.lang.Math.PI |
| import static java.lang.Math.sin as sine |
| import static java.lang.Math.cos as cosine |
| assert sine(PI / 6) + cosine(PI / 3) == 1 |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| Aliasing also works with normal imports too, not just static imports, |
| and it can be pretty handy for adding some shortcut notation to very |
| long class names as found in many frameworks, or for renaming methods or |
| constants with non-obvious names, or not following your naming |
| convention standards. |
| |
| [[Groovy15releasenotes-Generics]] |
| === Generics |
| |
| A somewhat more controversial feature of Java 5 also finds its way in |
| the latest release of Groovy 1.5 with Generics. Initially, it may feel |
| odd to add even more typing information to a dynamic language, after |
| all. Java developers usually believe that because of type erasure (for |
| backward compatibility reasons with older versions of Java) no |
| information is left in the class bytecode to represent the generic type. |
| However, this is wrong, since through the reflection API, you are able |
| to introspect a class to discover the types of its fields or of its |
| methods arguments with the generics details. |
| |
| So for instance, when you declare of field of type *List<String>*, |
| somewhere in the bytecode, this information is kept in the form of some |
| meta-information, although this field is really just of type *List*. |
| This kind of reflexive information is used by enterprise frameworks like |
| JPA or Hibernate to be able to relate a collection of elements from an |
| entity to the entity representing the type of these elements. |
| |
| To put this into practice, let us check if the generics information is |
| kept on class fields: |
| |
| [source,groovy] |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| class Talk { String title } |
| class Speaker { |
| String name |
| List<Talk> talks = [] |
| } |
| def me = new Speaker(name: 'Guillaume Laforge', |
| talks: [new Talk(title: 'Groovy'),new Talk(title: 'Grails')]) |
| def talksField = me.class.getDeclaredField('talks') |
| assert talksField.genericType.toString() == 'java.util.List<Talk>' |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| We defined two classes: a Speaker class giving Talks at conferences. In |
| the Speaker class, the talks property is of type *List<Talk>*. Then, we |
| create a Speaker instance with two nice shortcuts for initializing the |
| name and talks properties, and for creating a list of Talk instances. |
| Once this setup code is ready, we retrieve the field representing the |
| talks, and we check that the generic type information is correct: |
| yes, *talks* is a *List*, but a *List* of *Talks*. |
| |
| [[Groovy15releasenotes-Covariantreturntypes]] |
| === Covariant return types |
| |
| In Java 5, if you have a method in a subclass with the same name and |
| parameter types as in a parent class, but with a return type derived |
| from the parent method’s return type, then we can override the parent |
| method. In Groovy 1.0, covariant return types were not supported. But in |
| Groovy 1.5, you can use them. Additionally, if you are trying to |
| override a method with a return type not deriving from the parent class |
| method’s return type, a compilation error will be thrown. Covariant |
| return types also work with parameterized types. |
| |
| Beyond the support of Java 5 features which brought a few additions to |
| the language, a few other syntax enhancements have been introduced in |
| Groovy 1.5, and we are going to discover them in the following section. |
| |
| [[Groovy15releasenotes-Syntaxadditions]] |
| == Syntax additions |
| |
| [[Groovy15releasenotes-Elvisoperator]] |
| === Elvis operator |
| |
| Apart from the Java 5 features that brought annotations, generics and |
| enums into Groovy, a new operator finds its way into the language: ?: |
| the Elvis operator. When you see the operator in question, you will |
| easily guessed why it was nicknamed that way - if not, think in terms of |
| Smiley. This new operator is, in fact, a shortcut notation for the |
| ternary operator. How many times are you using the ternary operator to |
| change the value of a variable if its content is null to assign it some |
| default value? The typical case in Java is as follows: |
| |
| [source,groovy] |
| ------------------------------------------------------------------------------- |
| String name = "Guillaume"; |
| String displayName = name != null ? name : "Unknown"; |
| ------------------------------------------------------------------------------- |
| |
| In Groovy, since the language is able to ``coerce'' types to boolean |
| values as needed (for instance where conditional expressions are |
| required like in if or while constructs), in this statement, we can omit |
| the comparison to null, because when a String is null, it is coerced to |
| false, so in Groovy, the statement would become: |
| |
| [source,groovy] |
| --------------------------------------------------------------------- |
| String name = "Guillaume" |
| String displayName = name ? name : "Unknown" |
| --------------------------------------------------------------------- |
| |
| However, you will still notice the repetition of the name variable, |
| which would violate the DRY principle (Don’t Repeat Yourself). As this |
| construct is pretty common, the Elvis operator was introduced to |
| simplify such recurring cases, and the statements become: |
| |
| [source,groovy] |
| ---------------------------------------------------------------- |
| String name = "Guillaume" |
| String displayName = name ?: "Unknown" |
| ---------------------------------------------------------------- |
| |
| The second occurrence of the name variable is simply omitted and the |
| ternary operator is no more ternary and is shortened to this more |
| concise form. |
| |
| It is also worth noticing that there are no side effects to this new |
| construct, since the first element (here the name) is not evaluated |
| twice as it would be the case with the ternary operator, so there’s no |
| need to introduce some intermediate temporary value to hold the result |
| of the first evaluation of the first element of the ternary operator. |
| |
| [[Groovy15releasenotes-Classicalforloop]] |
| === Classical for loop |
| |
| Although Groovy is not strictly speaking a 100% superset of Java, the |
| Groovy syntax comes closer to the Java syntax after each release, and |
| more and more Java code is also valid Groovy. The net benefit of this is |
| that when you begin with Groovy, you can copy and paste Java code in |
| your Groovy classes, and this should just work as expected. Then, over |
| time, as you learn the language, you start throwing away the semi-colons |
| which are not mandatory in Groovy, using GStrings (interpolated |
| strings), or closures, etc. Groovy offers a rather flat learning curve |
| to Java developers. |
| |
| However, there was one omission to this Java-syntax compatibility in the |
| fact the classical for loop inherited from Java’s C background wasn’t |
| allowed in Groovy. Initially, the Groovy developers thought it was not |
| the nicest syntax of all and preferred using the for / in construct |
| which was more readable. But as the Groovy users regularly asked for |
| this old construct to be also part of Groovy, the team decided to bring |
| it back to Groovy. |
| |
| With Groovy 1.5, you can either chose the Groovy for / in, or prefer the |
| classical for loop: |
| |
| [source,groovy] |
| ----------------------------------------------------------------------- |
| for (i in 0..9) println i |
| for (int i = 0; i < 10; i++) println i |
| ----------------------------------------------------------------------- |
| |
| At the end of the day, it is probably more a matter of taste, and long |
| time Groovy users usually prefer the most concise syntax with the for / |
| in loop instead. |
| |
| [[Groovy15releasenotes-Namedparameterswithoutparenthesis]] |
| === Named parameters without parenthesis |
| |
| With its malleable and concise syntax, and its advanced dynamic |
| capabilities, *Groovy is an ideal choice for implementing internal |
| Domain-Specific Languages*. When you want to share a common metaphor |
| between subject matter experts and developers, you can leverage Groovy |
| to create a dedicated business language which models the key concept and |
| business rules of your application. An important aspect of these DSLs is |
| to make the code very readable, and also easier to write by |
| non-technical persons. To achieve this goal even further, the grammar of |
| the language was tweaked to allow us to use named parameters without the |
| surrounding parenthesis. |
| |
| First of all, in Groovy, named parameters look like this: |
| |
| [source,groovy] |
| ------------------------------------------------------------------------------------------- |
| fund.compare(to: benchmarkFund, in: euros) |
| compare(fund: someFund, to: benchmark, in: euros) |
| ------------------------------------------------------------------------------------------- |
| |
| By adding new properties to numbers - which is possible in Groovy but |
| beyond the scope of this article - we can also write code like this: |
| |
| [source,groovy] |
| --------------------------------------- |
| monster.move(left: 3.meters, at: 5.mph) |
| --------------------------------------- |
| |
| Now by omitting parenthesis, the code can become a little clearer as |
| shown below: |
| |
| [source,groovy] |
| ------------------------------------------------------------------------------------------------------------------------------- |
| fund.compare to: benchmarkFund, in: euros |
| compare fund: someFund, to: benchmark, in: euros |
| monster.move left: 3.meters, at: 5.mph |
| ------------------------------------------------------------------------------------------------------------------------------- |
| |
| Obviously, this is not a big difference, but each statement becomes |
| closer to real plain English sentences, and removes the usual |
| boiler-plate technical code of the host language. This little |
| enhancement of the grammar of the Groovy language gives more options to |
| the designers of the business DSL. |
| |
| [[Groovy15releasenotes-Improvedtoolingsupport]] |
| == Improved tooling support |
| |
| A common show-stopper when Groovy was a young language, was the lack of |
| good tooling support: both the tool chain and the IDE support weren’t up |
| to the task. Fortunately, with the maturity and success of Groovy and |
| the Grails web framework, this situation has changed. |
| |
| [[Groovy15releasenotes-Introductionofthejointcompiler]] |
| == Introduction of the joint compiler |
| |
| Groovy is well-known for its transparent and seamless integration with |
| Java. But this is not just about being able to call Java methods from |
| Groovy scripts, no, the integration between both languages goes well |
| beyond that. For instance, it is totally possible to have a Groovy class |
| extending a Java class which in turns implements a Groovy interface, or |
| vice versa. This is something other alternative languages don’t alway |
| support, unfortunately. However, when mixing Groovy and Java classes |
| together, so far, you had to be careful when compiling both type of |
| classes by cleverly choosing the order of compilation, and when cyclic |
| dependencies were spanning both languages, you may have hit a ``chicken |
| and egg'' problem. Fortunately with Groovy 1.5, this is not the case |
| anymore, and thanks to a contribution from JetBrains, the makers of the |
| award winning http://www.jetbrains/idea/[Java IDE IntelliJ IDEA], a |
| ``joint'' compiler is available with which you can compile both Groovy |
| and Java sources together in one go without having to think about |
| dependencies between classes. |
| |
| If you want to use the joint compiler from the command-line, you can |
| call the groovyc command as usual, but specify the -j flag which will |
| enable the joint compilation: |
| |
| ---------------------------------------------------- |
| groovyc *.groovy *.java -j -Jsource=1.4 -Jtarget=1.4 |
| ---------------------------------------------------- |
| |
| For passing parameters to the underlying javac command, you can prefix |
| the flags with the J prefix. You can also use the joint compiler through |
| its Ant task from you Ant or Maven build files: |
| |
| [source,xml] |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc" classpathref="my.classpath"/> |
| <groovyc srcdir="${mainSourceDirectory}" |
| destdir="${mainClassesDirectory}" |
| classpathref="my.classpath" |
| jointCompilationOptions="-j -Jsource=1.4 -Jtarget=1.4" /> |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| [[Groovy15releasenotes-MavenpluginforGroovy]] |
| === Maven plugin for Groovy |
| |
| For the Maven users, there is also a fully featured Maven plugin hosted |
| at Codehaus which allows you to build your Java / Groovy applications: |
| compile your Groovy and Java code, generate documentation from the |
| JavaDoc tags, or it even lets you write your own Maven plugins in |
| Groovy. There is also a Maven archetype to bootstrap your Groovy project |
| more rapidly. |
| |
| [[Groovy15releasenotes-TheGroovyDocdocumentationtool]] |
| === The GroovyDoc documentation tool |
| |
| As a Java developer, you are used to documenting your code through |
| JavaDoc tags in the comments of your classes, interfaces, fields, or |
| methods. In Groovy, you can also use such tags in your comments, and |
| have them being used by a tool called GroovyDoc to generate the |
| equivalent JavaDoc documentation for all your Groovy classes. |
| |
| There’s an Ant task you can define then use to generate the |
| documentation as follows: |
| |
| [source,xml] |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <taskdef name="groovydoc" |
| classname="org.codehaus.groovy.ant.Groovydoc"> |
| <classpath> |
| <path path="${mainClassesDirectory}"/> |
| <path refid="compilePath"/> |
| </classpath> |
| </taskdef> |
| |
| <groovydoc destdir="${docsDirectory}/gapi" |
| sourcepath="${mainSourceDirectory}" |
| packagenames="**.*" use="true" |
| windowtitle="Groovydoc" |
| private="false"/> |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| [[Groovy15releasenotes-NewinteractiveshellandtheSwingconsole]] |
| == New interactive shell and the Swing console |
| |
| Groovy distributions always contained two different shells: a |
| command-line shell as well as a Swing console. Groovysh, the |
| command-line shell, has never been very friendly in terms of |
| interactions with its user: whenever you wanted to execute a statement, |
| you had to type `go' or `execute' after each one, so that it got |
| executed. For quick prototyping or playing with some new API, typing |
| `go' each time was very cumbersome. The situation has changed in Groovy |
| 1.5, since a new interactive shell is born. No need to type `go' |
| anymore. |
| |
| This new shell features several enhancements, such as the use of the |
| JLine library which provides ANSI coloring, tab completion for commands, |
| line editing capabilities. You can work with different script buffers, |
| remember already imported classes, load existing scripts, save the |
| current script to a file, browse the history, etc. For detailed |
| explanations of the supported features, please have a look at |
| the http://www.groovy-lang.org/groovysh.html[documentation]. |
| |
| The command-line shell isn’t the only one that received some care, the |
| Swing console has also been improved, with a new toolbar, with advanced |
| undo capabilities, the possibility to increase or decrease the font |
| size, syntax highlighting. A lot of polishing has been applied to the |
| console. |
| |
| [[Groovy15releasenotes-IntelliJIDEAJetGroovyplugin]] |
| === IntelliJ IDEA JetGroovy plugin |
| |
| I will save the best of tooling support till the end of this section by |
| mentioning the JetGroovy plugin: a free and Open Source IntelliJ IDEA |
| plugin dedicated to the support of both Groovy and Grails. This plugin |
| has been developed by JetBrains themselves, and provides unmatched |
| support for both the language and the web framework. |
| |
| To list a few of the available features of the Groovy support: |
| |
| * *Syntax highlighting* for all the syntax, plus different warnings for |
| types not recognized, or when static type information is not known to |
| help spot potential errors. |
| * Ability to *run Groovy classes, scripts and JUnit test cases written |
| in Groovy*. |
| * *Debugger*: You can debug step by step across your Java and Groovy |
| code, set breakpoints, show variables, the current stack, etc. |
| * Joint compiler: the compiler *compiles both Groovy and Java* classes |
| together and is able to resolve dependencies between both languages. |
| * *Code completion* for packages, classes, properties, fields, |
| variables, methods, keywords, and even specific support for the Swing UI |
| builder. |
| * Advanced class search and find usage. |
| * *Refactorings*: most of the usual refactorings you’ve come to love in |
| Java are available as well and work across Java and Groovy, like |
| ``surround with'', introduce, inline or rename a variable, renaming for |
| packages, classes, methods, and fields. |
| * *Imports optimizations and code formatting*. |
| * Structure view: to have a bird’s eye view of your classes. |
| |
| At the end of the day, you won’t even notice whether you’re developing a |
| class in Groovy or in Java, considering the level of interplay and |
| support offered inside IntelliJ IDEA. This is definitely a plugin to |
| install if you’re considering adding some dose of Groovy in your Java |
| project, or if you plan to develop Grails applications. |
| |
| More information can be found |
| on http://www.jetbrains.net/confluence/display/GRVY/Groovy+Home[JetBrains |
| website]. |
| |
| Although I’m only mentioning the plugin for IntelliJ IDEA, for your |
| Groovy developments, you don’t have to change your habits. You can also |
| use the Eclipse plugin which is regularly improved by the IBM Project |
| Zero developers, or Sun’s brand new support of Groovy and Grails in |
| NetBeans. |
| |
| [[Groovy15releasenotes-Performanceimprovements]] |
| == Performance improvements |
| |
| Along with new features, this new release of Groovy brings noticeable |
| performance improvements as well as lower memory consumption, compared |
| to previous versions. In our informal benchmarks measuring the duration |
| of all our test suites, we noticed speed improvements between 15% to 45% |
| compared with our beta versions of Groovy 1.5 - and certainly higher |
| figures can be expected by comparing with the now old Groovy 1.0. More |
| formal benchmarks have yet to be developed, but those figures have also |
| been confirmed by developers from an insurance company that is using |
| Groovy to write the business rules of their policy risk calculation |
| engine, and from another company who ran several tests on highly |
| parallel machines. Overall, Groovy 1.5 should be faster and leaner in |
| most situations. Your mileage may vary depending on your own context of |
| usage of Groovy. |
| |
| [[Groovy15releasenotes-Enhanceddynamiccapabilities]] |
| == Enhanced dynamic capabilities |
| |
| Through the symbiotic relationships between the Groovy and Grails |
| projects, new dynamic capabilities have been introduced in Groovy, after |
| having matured in the heart of Grails. |
| |
| Groovy is a dynamic language: put simply, it means that certain things |
| like method dispatch happens at runtime, instead of at compile-time as |
| it is the case of Java and other languages. There is a specific runtime |
| system, called the MOP (stands for Meta-Object Protocol) that is |
| responsible for the dispatching logic. Fortunately, this runtime system |
| is open enough so that people can hook into the system and change its |
| usual behavior. For each Java class and for each Groovy instance, there |
| is an associated meta-class which represents this runtime behavior of |
| your objects. Groovy offered various ways to interact with the MOP by |
| defining custom meta-classes by extending some base class, but thanks to |
| the contribution from the Grails project, a groovier kind of meta-class |
| is available: the expando meta-class. |
| |
| Again,code samples are easier to help us understand the concept. In the |
| following example, the msg String instance has got a meta-class that we |
| can access through the metaClass property. Then we change the meta-class |
| of the *String* class to add a new method called up to the String class, |
| to have a shortcut notation for the *toUpperCase()* method. To do so, we |
| assign a closure to the up property of the meta-class which is created |
| as we assign it the closure. This closure takes no argument (hence why |
| it starts with an arrow), and we call the *toUpperCase()* method on the |
| delegate of the closure, which is a special closure variable which |
| represents the real object (here the String instance). |
| |
| [source,groovy] |
| ---------------------------------------------------------------------------------------------------------------------- |
| def msg = "Hello!" |
| println msg.metaClass |
| String.metaClass.up = { -> delegate.toUpperCase() } |
| assert "HELLO!" == msg.up() |
| ---------------------------------------------------------------------------------------------------------------------- |
| |
| Through this meta-class, you can query the methods and/or properties |
| which are available: |
| |
| [source,groovy] |
| -------------------------------------------------------------------------------------------------------------------------------------------------- |
| // print all the methods |
| obj.metaClass.methods.each { println it.name } |
| |
| // print all the properties |
| obj.metaClass.properties.each { println it.name } |
| -------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| You can even check that a certain method or property is available, with |
| a finer granularity than through any instanceof check: |
| |
| [source,groovy] |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| def msg = 'Hello!' |
| if (msg.metaClass.respondsTo(msg, 'toUpperCase')) { |
| println msg.toUpperCase() |
| } |
| if (msg.metaClass.hasProperty(msg, 'bytes')) { |
| println foo.bytes.encodeBase64() |
| } |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| These mechanisms are extensively used in the Grails web framework for |
| instance to create dynamic finders: no need for DAOs in most |
| circumstances, as you are able to call a *findByTitle()* dynamic method |
| on a Book domain class. Through meta-classes, Grails automatically |
| decorates the domain classes with such methods. Furthermore, if the |
| method doesn’t exist yet, it will be created and cached on first use. |
| This can be accomplished by other advanced hooks as explained below. |
| |
| Beyond those examples we’ve seen so far, expando meta-classes also |
| provide some complementary hooks. Four other kind of methods can be |
| added to an expando meta-class: |
| |
| * *invokeMethod()* lets you intercept all methods calls, |
| * while *methodMissing()* will be called on last resort only of no other |
| method is found. |
| * *get/setProperty()* intercepts access to all properties, |
| * whereas *propertyMissing()* is called when no property can be found. |
| |
| With expando meta-classes, customizing the behavior of the types of your |
| application becomes easier and can save precious time of development |
| compared with the previous version of Groovy. Obviously, not everybody |
| needs to use those techniques, but they can be handy in a number of |
| situations where you want to apply some AOP (Aspect Oriented Techniques) |
| to decorate your classes, and when you want to simplify and make more |
| readable the business code of your application, by removing some |
| unnecessary boiler-plate code. |
| |
| [[Groovy15releasenotes-Swingonsteroids]] |
| == Swing on steroids |
| |
| The Groovy project has the chance to have a team of talented Swing |
| developers who worked hard to enhance the capabilities of Groovy to |
| build user interfaces in Swing. The basic brick for building Swing UIs |
| in Groovy is the SwingBuilder class: at a syntactical level in your |
| source, you can visually see how Swing components are nested within each |
| other. A simplistic example from the Groovy website shows how to simply |
| create a little GUI: |
| |
| [source,groovy] |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| import groovy.swing.SwingBuilder |
| import java.awt.BorderLayout |
| import groovy.swing.SwingBuilder |
| import java.awt.BorderLayout as BL |
| |
| def swing = new SwingBuilder() |
| count = 0 |
| def textlabel |
| def frame = swing.frame(title:'Frame', size:[300,300]) { |
| borderLayout() |
| textlabel = label(text:"Clicked ${count} time(s).", constraints: BL.NORTH) |
| button(text:'Click Me', actionPerformed: { count++; textlabel.text = "Clicked ${count} time(s)."; println "clicked"}, |
| constraints:BorderLayout.SOUTH) |
| } |
| frame.pack() |
| frame.show() |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| In the novelties, the Swing builder concept has been extend to provide |
| custom component factories. There are additional modules, not bundled |
| with Groovy by default, which integrates the Swing components from JIDE |
| or from the SwingX project into the usual Swing builder code. |
| |
| Although this topic would deserve a full article, I’m only going to list |
| some of the other improvements in this release, for instance, the bind() |
| method. Inspired by the beans binding JSR (JSR-295), you can easily bind |
| components or beans together to have them react upon changes made on |
| each other. In the following example, the size of the insets of the |
| button will be changed according to the value of the slider component: |
| |
| [source,groovy] |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| import groovy.swing.SwingBuilder |
| import java.awt.Insets |
| |
| swing = new SwingBuilder() |
| frame = swing.frame { |
| vbox { |
| slider(id: 'slider', value:5) |
| button('Big Button?!', margin: bind(source: slider, sourceProperty:'value', converter: { [it, it, it, it] as Insets })) |
| } |
| } |
| frame.pack() |
| frame.size = [frame.width + 200, frame.height + 200] |
| frame.show() |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
| Binding components together is such a common task when building user |
| interfaces, that this task has been simplified through this binding |
| mechanism. There are also some other automatic binding options that can |
| be used, but again, a dedicated article would probably be better. |
| |
| In other new and noteworthy features, a few handy new methods have been |
| added which leverage closures to call the infamous SwingUtilities class, |
| and to start new threads: edt() will call _invokeAndWait()_, |
| while *doLater()* will call *invokeLater()*, and *doOutside()* will just |
| launch a closure in a new thread. No more ugly anonymous inner classes: |
| just use closures through those shortcut methods! |
| |
| Last but not least, separating the description of the view and its |
| associated behavior logic has never been easier, thanks to the build() |
| method on SwingBuilder. You can create a separate script which only |
| contains the view, while the interactions or bindings between components |
| are in the main class, making a clearer separation in the MVC model. |
| |
| [[Groovy15releasenotes-Summary]] |
| == Summary |
| |
| In this article, the new and noteworthy features have been outlined, but |
| we have barely scratched the surface of this new version of Groovy. The |
| big highlights are mainly around the new Java 5 features, such as |
| annotations, enums or generics: it makes Groovy perfectly capable of |
| being integrated nicely and seamlessly with Enterprise frameworks such |
| as Spring, Hibernate, or JPA. With the improvements in the syntax and |
| with the enhanced dynamic capabilities, Groovy will let you customize |
| your business logic by creating embedded Domain-Specific Languages, that |
| you can easily integrate at the extension points of your application. |
| The developer experience has progressed significantly through the work |
| poured in the tooling support, this is no more a show stopper to the |
| adoption of Groovy. Overall, with Groovy 1.5, the goal of simplifying |
| the life of developers has never been so well fulfilled, and Groovy |
| should definitely be part of all the Java developers’ toolbox. |
