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.

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 . 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.

Things to be aware of

semicolon is 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 are private by default and classes public.

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

Error rendering macro 'link' : Link needs a name and a URL as arguments.

instead

the throws clause in method heads is not supported at the moment, because there is no difference between checked and unchecked exceptions

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.