Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 33 Next »

Groovy tries to be as natural as possible for Java developers. We've tried to follow the principle of least surprise when designing Groovy, particularly for developers learning Groovy who've come from a Java background.

Here we list all the major differences between Java and Groovy.

Default imports

All these packages and classes are imported by default, i.e. you do not have to use an explicit import statement to use them:

  • java.io.*
  • java.lang.*
  • java.math.BigDecimal
  • java.math.BigInteger
  • java.net.*
  • java.util.*
  • groovy.lang.*
  • groovy.util.*

Common gotchas

Here we list the common things you might trip over if you're a Java developer starting to use Groovy.

  • == means equals on all types. In Java there's a wierd part of the syntax where == means equality for primitive types and == means identity for objects. Since we're using autoboxing this would be very confusing for Java developers (since x == 5 would be mostly false if x was 5 (smile) . So for simplicity == means equals() in Groovy. If you really need the identity, you can use the method "is" like foo.is(bar). This does not work on null, but you can still use == here: foo==null.
  • in is a keyword. So don't use it as a variable name.
  • When declaring array you can't write
    you need to write
  • If you were used to write a for loop which looked like
    in groovy you can use that too, but you can use only one count variable. Alternatives to this are
    or
    or

Things to be aware of

  • Semicolons are optional. Use them if you like (though you must use them to put several statements on one line).
  • The return keyword is optional.
  • You can use the this keyword inside static methods (which refers to this class).
  • Methods and classes are public by default.
  • Protected in Groovy is the equivalent of both package-protected and protected in Java. i.e. you can have friends in the same package - or derived classes can also see protected members.
  • Inner classes are not supported at the moment. In most cases you can use closures instead.
  • The throws clause in a method signature is not checked by the Groovy compiler, because there is no difference between checked and unchecked exceptions.
  • You will not get compile errors like you would in Java for using undefined members or passing arguments of the wrong type. See Runtime vs Compile time, Static vs Dynamic.

Uncommon Gotchas

Java programmers are used to semicolons terminating statements and not having closures. Also there are instance initializers in class definitions. So you might see something like:

Many Groovy programmers eschew the use of semicolons as distracting and redundant (though others use them all the time - it's a matter of coding style). A situation that leads to difficulties is writing the above in Groovy as:

This will throw a MissingMethodException!

The issue here is that in this situation the newline is not a statement terminator so the following block is treated as a closure, passed as an argument to the Thing constructor. Bizarre to many, but true. If you want to use instance initializers in this sort of way, it is effectively mandatory to have a semicolon:

This way the block following the initialized definition is clearly an instance initializer.

New features added to Groovy not available in Java

  • Error rendering macro 'link' : Link needs a name and a URL as arguments.
  • native
    Error rendering macro 'link' : Link needs a name and a URL as arguments.
    for lists and maps
  • Error rendering macro 'link' : Link needs a name and a URL as arguments.
    and GPath support
  • native support for
    Error rendering macro 'link' : Link needs a name and a URL as arguments.
  • polymorphic
    Error rendering macro 'link' : Link needs a name and a URL as arguments.
    and powerful
    Error rendering macro 'link' : Link needs a name and a URL as arguments.
  • dynamic and static typing is supported - so you can omit the type declarations on methods, fields and variables
  • you can embed expressions inside
    Error rendering macro 'link' : Link needs a name and a URL as arguments.
  • lots of new helper methods added to the
    Error rendering macro 'link' : Link needs a name and a URL as arguments.
  • simpler syntax for writing
    Error rendering macro 'link' : Link needs a name and a URL as arguments.
    for both properties and adding event listeners
  • Error rendering macro 'link' : Link needs a name and a URL as arguments.
    using the ?. operator, e.g. "variable?.field" and "variable?.method()" - no more nested ifs to check for null clogging up your code
  • No labels