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.
Floating point number literals are BigDecimals by default. So when you type 3.14, Groovy won't create a double or a float, but will instead create a BigDecimal. This might lead people into believing that Groovy is slow for arithmetics!
If you really want to use floats or doubles, be sure to either define such numeric variables with their float or double types, like in:
Or else, you can also use suffixes like:
See also our section on Math with Groovy.
All these packages and classes are imported by default, i.e. you do not have to use an explicit
import statement to use them:
Here we list the common things you might trip over if you're a Java developer starting to use Groovy.
When declaring array you can't write
you need to write
If you are used to writing a for loop that looks like
in groovy you can use that too, but you can use only one count variable. Alternatives to this are
returnkeyword is optional.
thiskeyword inside static methods (which refers to this class).
Protectedin Groovy has the same meaning as protected in Java, i.e. you can have friends in the same package and derived classes can also see protected members.
throwsclause in a method signature is not checked by the Groovy compiler, because there is no difference between checked and unchecked exceptions.
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
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.
Another document lists some pitfalls you should be aware of and give some advice on best practices to avoid those pitfalls.