Mundane Java has two types of character-type literals: character literals, enclosed in single-quotes, and string literals, enclosed in double-quotes.

1/* Character literal, enclosed in single-quotes */
2char ch = 'c';
3/* String literal, enclosed in double-quotes */
4String s = "This is a string.";

One of the first things not backwards-compatible with Java that a new Groovy user may notice is that single-quotes now delimit strings as well.

Suppose that we have a stateless but computationally-intensive piece of code involving a lot of function calls, which is for some reason written in Groovy.

1package gl.lin
2
3class SlowFib {
4  static int fib(int n) {
5    n <= 1? n : fib(n-1) + fib(n-2)
6  }
7}

Obviously, the algorithm here is pretty much the worst one possible — it has exponential run-time, but calculating the Fibonacci sequence can be calculated in linear time. But imagine for the time being that this is real code. The important thing is that this code makes lots of function calls. Also important is how the function is stateless — it accesses no data outside of its locals, and is non-virtual due to its staticness (ie, it could be called with one instruction were this native code).

Now say we want to write a program that maps a sequence of input integers to the corresponding Fibonacci number. A simple single-threaded implementation is below.

The private access modifier is arguably the most important in the context of software engineering in Java, and more so in Groovy where everything is public (sort of) by default. By declaring something private, the programmer can be certain that no code outside the current lexical scope can see the member; thus, there will never be any external dependencies on its presence or behaviour, allowing it to be easily changed or removed without widespread consequences. Of course, it could be expected of Groovy to merely parse and discard the private keyword, substituting it with the “implicit-public” access modifier instead. Fortunately, it doesn’t do that.

It does something much worse.

Groovy has an entire three different types of type-casts that can occur. The first two are inherited from Java, albeit with substantially more permissive semantics.

One of the most obvious ways with which Groovy tries to “reduce” boiler-plate is to make all members (both variables and methods) of any class public by default, as opposed to Java in which members are package-private by default. While this is already a questionable design decision at best, an interesting facet of the implementation is that implicitly public member variables are private, though another Groovy feature masks this detail when operating within Groovy.

We’ll start with a Groovy class that just has some members of varying types and access modifiers. You can compile these files yourself by dropping them into the base project.

In the past two weeks, we’ve looked at how horribly Groovy handles something as simple as function call arguments. There is yet one more horror Groovy brings to the table: its conception of named arguments.

Named arguments (also known as “keyword arguments”, or just “kwargs”, in some contexts) allow the programmer to specify arguments to a function by name, rather than by position, enhancing readability and in many cases writability, as the meaning of each argument is clarified at use site. It also has the advantage of allowing some arguments to be specified without specifying the preceding ones, in the case of arguments which also have defaults. Examples of languages which support this concept are Python and OCaml.

As mentioned last week, one of the main reasons Java has method overloading was to emulate optional arguments, albeit verbosely. In the below example, our multiple definitions of doSomething allow it to be called with any prefix of its argument list, the other parameters “defaulting” to something that the implementor considered reasonable.

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.