Java permits the programmer to define more than one function or method of the same name, which can be differentiated based on argument count and types; this is called “overloading”. While most modern languages consider it a fairly bad thing, it allows Java to partially overcome two serious deficiencies:

• Java does not have default arguments. With overloading, you can define versions of a function with fewer arguments, which simply call the real version with the missing arguments filled in.

• Java gives no way to generically perform identical operations across disparate types, especially when it comes to arrays. Overloading allows the same function to be copy-pasted with different type declarations, or to do forwarding with conversions, in order to achieve such operations.

Java 1.5 introduced into the language a concept called generics. In environments that do generics correctly, a generic type parameter specifies the type of elements contained within an abstract data type. C++’s templates have this effect — it is fundamentally impossible for a list<string> to ever contain anything other than strings.

For the sake of backwards compatibility, Java instead handles generics with type erasure and implicit casting. Type erasure means that the Java compiler determines the least general type that the ADT can possibly have (eg, Object for List, Comparable for TreeMap, etc) according to its generic declaration, and then internally uses that type, and provides extra information in the generated .class files so that the compiler knows what generics were originally there. Whenever a value with a more specific generic type is used, the compiler implicitly casts it back down to the type that “should” be there.

In Java, a default constructor is simply one without arguments. If you make a non-abstract class with no explicit constructor, the compiler gives your class a do-nothing default default constructor. This happens in Groovy as well. This is not the subject of this post. Also consider that the title of the post did not say “every Groovy class” — that would be a far less disturbing topic.

At first glance, Groovy’s scope rules are much like Java’s. A variable name will refer to a local variable, a variable from a containing scope, or the superclass or -interface of a class scope, or possibly from static imports. Except in contrived cases, the system is fairly easy to reason about, and in any case the compiler will catch you if you do something wrong.

Groovy, of course, had to take a decent system and try to make it more “dynamic”. In some ways, the scoping system is more like Python, especially in that variable existence is determined partially at run-time. Python’s rules, however, are fairly simple, and make that system basically work.

Today, we’ll be talking about how Groovy doesn’t seem to have a consistent idea of what an identifier is. It’s not a very large topic, and it really isn’t a problem, but it is a topic that nevertheless merits mention, and it allows me to introduce…

The first look at any programming language often begins with the traditional “hello world” program. Below is Java’s, for reference.

1public class HelloWorld {
2  public static void main(String args[]) {
3    System.out.println("hello world");
4  }
5}

Groovy’s, on the other hand, looks like this:

1class HelloWorld {
2  static def main(args) {
3    println("hello world")
4  }
5}

Gr- — (Javanese) Agglunative prefix, typically indicating expectation of a painful experience, often due to lack of forethought or impropper planning.

Example constructs include:

• Groovy — Adjective. Characterised by a large number of hacks attempting to make things better, but which really only increase the number of problems by an order of magnitude. “That’s some groovy code you’ve got there. I especially like how it uses the query parameters to dynamically select the class and static method to execute.”

• Grail(s) — Verb (almost always found in the singular present). To inflict suffering and confusion by means of unnecessary complexity, self contradiction, and annoying surprises separated by excrutiating waits. “It really grails me how this ‘convention over configuration’ framework requires three multi-thousand-line configuration files to run.”

• Gradle — Noun. An obstensibly comfortable, metaphorical location in which something is cradled before finally succumbing to death. “After having been in gradle for a few months, we found that the code had become impossible to update, due to library version conflicts.”