Groovy 1.1 RC 2 is released today, with the final release expected a week or so from now. Despite the very warm welcome Groovy has received since its inception, there is still some level of confusion about what Groovy actually is . Its special relationship with Java is well known, but what that relationship consists of exactly is sometimes less clear. To give some insight, Guillaume Laforge answers some questions below. Guillaume is the official Groovy Project Manager, a very long-time Groovy committer, and also the spec lead of JSR-241 , the JSR standardizing the Groovy language. Along with Dierk Koenig and others, he co-authored the " Groovy in Action " (fondly referred to as "GINA") bestseller, published by Manning. In his professional life, Guillaume is the Vice-President of Technology of G2One , a company dedicated to providing professional services around Groovy and Grails (training, support, consulting).

Guillaume, let's begin by examining some statements about Groovy. "Groovy is Java." What does that mean, exactly?

Groovy and Java are two languages that target the same runtime environment: the Java Virtual Machine. Java is a statically-typed language, while Groovy is a dynamic language. But despite their differences, both languages share the same platform, the same object inheritance model, the same threading model, the same security model, and the same libraries (the JDK and any JAR you want). Both will compile down to standard Java bytecode. You can even have a Groovy class extending a Java class, which in turn implements a Java interface, or vice versa! You can mix and match Groovy and Java, in whichever order you want.

Furthermore, Groovy's syntax is very close to that of Java: you can almost copy and paste 95% of Java code into your Groovy classes, and it will also be valid Groovy! But Groovy also adds some "syntactic sugar" to Java, like list, map and regular expression literals, some new operators, and some handy shortcut notations to make the code more concise. And as you start to learn Groovy, it is just plain Java in the beginning, and over time, you master more features provided by Groovy, at your own pace.

So although Groovy and Java are different, they are also the same in the sense that they resemble each other very much and they live on the same platform, and can be mixed however you like. Hence why we sometimes say that "Groovy is Java".

Another statement about Groovy is: "Groovy is an implementation detail of Java APIs." Can you comment?

Just as sometimes people say "Groovy is Java", whenever you mix some Groovy and Java classes together, it's really just a matter of implementation choice. If you feel this particular part of your application should be written in Groovy because Groovy's syntax is more expressive and readable, or because Groovy has got some more powerful abstractions or APIs, well, you can write a specific class in Groovy instead of Java. It's an implementation detail, because when you use this class further down the road, when compiled to bytecode and running inside the JVM, you won't care at all whether the bytecode comes from a Java class or a Groovy class. Also, if sometimes you want the raw power of Java which is faster than Groovy, for numerical calculations, for instance, you can use Java instead of Groovy. At the end of the day, just as you use the best tool for the job, here, you can use the best language for the given task. And it's just an "implementation detail"!

"Groovy is a superset of Java." Is this perception completely true or only partially?

It's almost a superset of Java, as the grammar of Groovy is derived from the Java grammar. However, there are a few differences here and there which make both languages different enough so that Groovy is not a direct superset of Java. Fortunately, both are close enough that Java developers really feel at ease with developing Groovy code.

Originally, we felt Groovy could perhaps fix some flaws in the Java language—like the lack of closures, of list and map literals, etc. It may sound a little presumptuous, obviously, knowing all the great minds and developers who built Java, but we felt we could at the same time simplify the life of Java developers, while giving them access to more powerful features which were not available in Java. And we definitely do care very much about the "seamless integration" experience of mixing Groovy and Java at the same time, as a result of which we've thought that Groovy should also support Java 5 features like annotations, enums, static imports or generics. That's why Groovy 1.1 offers support for all these things, so that you can use enterprise frameworks at full steam: you can write JPA annotated beans, mark your Spring services @Transactional, make Hibernate understand the type of the elements of your typed collections, etc. Groovy 1.1 is the sole alternative dynamic language for the JVM that supports annotations, enums or generics. So, whenever you want to use frameworks like Spring, Hibernate, JPA, TestNG, JUnit 4 at their full power, and use an alternative language to save some pain in the process, your best bet will be to use Groovy.

And, it is definitely one of our goals to make Groovy even more of a Java superset. For instance, the decision to support annotations, generics, enums, static imports or the old for loop in Groovy 1.1 was with the idea in mind to be more and more a superset. And for future versions of Groovy, we aim at becoming almost (if not completely) a Java superset by supporting nested classes, anonymous inner classes, etc. Perhaps Groovy 2.0 will be considered just a Java-superset on steroids!

There seems to be some confusion around the Groovy/Java relationship and also in the way in which Groovy differs from other scripting languages. So, if Groovy is Java in the ways described above, how are the others not Java?

Most of the other alternative languages for the JVM often come from another planet, somehow, in the sense that they are just "ports" of an already existing language. And the problem is that those existing languages come with their own APIs, their own object models, their own security models, their own threading models: all of these are usually quite different from what those concepts are in the Java world. By using such languages on the JVM, you may come across some compatibility issues, and you will suffer from the "impedance mismatch" between those two different worlds. You will have to switch from one world to another every time you cross the border between the two languages.

Moreover, when having to learn new APIs and other models of programming, you lose all the benefits of the long years you've spent learning Java, and you don't leverage your skills as much as you could. Using Groovy in combination with Java allows you to protect all your investment (in terms of skills, trainings, books, application servers, etc), without requiring a huge effort to learn new concepts and a new platform. In other words, Groovy offers a rather flat learning curve.

Groovy owes a lot to those other scripting languages, because a lot of inspiration was taken from them—after all, copying others is probably the best form of flattery. But Groovy adopted the great concepts from those languages and adapted them to the Java ecosystem, to give them a Java feel, to keep on following the same philosophy.

Perhaps part of the confusion lies in the name "Groovy". If it had been called something like "QuickJava" or "ScriptedJava", maybe the special connection between Groovy and Java would have been clearer. What's the origin of the name?

Perhaps you know that Groovy's own grammar is directly derived from the Java 5 grammar? Adding annotations, generics, and enums to Groovy was easy, because we were using Java's grammar as the base for our own grammar. So perhaps we could have called Groovy something like "DerivedJava"? But, well, it doesn't sound that good, actually.

When Groovy was created initially by James Strachan and Bob McWhirter in August 2003, James always used to tell Bob things like: "Hey, Bob, wouldn't it be groovy if Java supported closures?", or "Wouldn't it be groovy if we could have properties in Java?". That's the true origin of the name "Groovy": the original creators' vision was to have a groovier Java, without having to wait for Java 5, 6, 7, or 8 for benefiting from these features. I mentioned closures: when do you think closures will really be available in Java? Or properties: will we ever have a concise and simple syntax for defining properties in Java, rather than having to write all those boiler-plate code snippets of getters and setters? Well, we didn't want to wait, and we wanted to simplify life for Java developers right now, not in several years from now. So we had to do something Groovy!

How were the specific characteristics that define Groovy chosen? For example, the 'def' keyword, the GStrings, the absent semi-colons? Who and how was it decided to implement features such as these?

Groovy is a language developed by pragmatic developers for other Java developers. We wanted the powerful features of other existing languages in Java, so we ended up creating a close Java cousin: Groovy. Some syntax elements come almost directly from other languages like Smalltalk, Ruby or Python, with some little tweaks so that the code still looks enough like Java code. Most of the language syntax is directly derived from Java, and GStrings, maps, lists, and regular expressions really look a lot like how they are in the other languages I mentioned. Sometimes a colon is used instead of an arrow, or a dollar sign is used instead of a hash sign. But Groovy's syntax has almost been set in stone from pretty early on in the life of the project, and not much has changed over time.

The evolution of the language is decided through regular meetings that I organize every year, in London or Paris, where most of the key Groovy committers meet for two days, to discuss the roadmap of the language. Those meetings lay the groundwork for the evolution of the language, but the details, or even some new features, are discussed more extensively, in the open, on our developer mailing-lists—and everybody is free to participate in the evolution of the language, which is the strength of Open Source!

Now, for the specific examples you mentioned... The 'def' keyword was added in 2004 I believe, after the first meeting of the JSR-241 (the JSR standardizing the Groovy language) and the Groovy developers. Before, no keyword was needed when you wanted to omit type information, but with this rule, we had some other problems, because, for instance, we couldn't distinguish between a declaration and an assignment, and we wanted to be able to make this distinction. So we tried to find a new keyword for defining untyped variables. We hesitated between 'any', 'def', or 'var' like in JavaScript. I used to prefer 'any' because those variables could be of 'any' type, but the concensus came around 'def' because we were 'def'-ining variables.

GStrings (also called interpolated strings in other languages) look a lot like the ones found in Python: we use dollars to denote the place-holders where variables are inserted.

Regarding the absence of semi-colons, you know that you can still use them in Groovy if you really want to, especially when you come from Java, it's a habit to put them at the end of every statement. But we felt that semi-colons weren't useful at all. Semi-colons were mainly in languages like C or Java because they helped the parser to do its job, but frankly, it's painful to have to help the parser: it should be clever enough to understand where a statement ends. You save some characters and you gain some more readability.

Let's now look under the hood a little bit. When I run the 'gcompile' Ant task, what happens under the hood, exactly?

Groovy has its own compiler: groovyc. Groovyc, like javac, will parse your source code, will create some in-memory representation (an Abstract Syntax Tree), and from this representation, it will create some bytecode instructions that will be written in a class file, or in-memory, if you evaluate your Groovy code at runtime—for instance, if you interpret some business rules stored in a database, or an XML file. The process of the Groovy compiler is in fact very similar to javac.

So, as you explained, Groovy is untyped. However, when I use a Java debugger to step through Groovy, I see that my objects have types. How does that change take place?

Groovy supports both static typing or dynamic typing. It's your choice: if you want to explicitely type a variable, you're free to do so, and if you don't care about the type information, you can omit it by using the 'def' keyword when defining your variables. But in the end, when a class is instantiated, and you've got an object inside your JVM, this object is always an instance of its class. So even if you don't type your variables or parameters, your objects will always have a type, and that's what your Java debugger will show you.

Aside from the 'syntactic sugar', what else does Groovy provide?

Actually, there's a lot more, of course. There are some special notations for creating lists, maps and regular expressions, there are some nice shorcut notations for navigating graphs of objects without the need to check for nullity at each stage, there are some additional operators, you can omit certain keywords, like 'public', in most cases, etc. This is the 'syntactic sugar' that Groovy provides over Java. But, there's more.

First of all, the libraries. Groovy's got its own GDK: Groovy Development Kit. It is not a development kit in the same sense as in Java, but it refers to the way Groovy enhances the core JDK classes to give them some additional methods. Have you ever dreamed of adding a join() method to an array of Strings? How many times have you written some utility classes to get the content of a text file? Wouldn't it have been 'groovy' if those utility methods had been present in core classes like String? But that's not possible since those classes are final: you can't extend them to add new useful methods. But in Groovy, you can! So we've added several such methods to decorate common types through the JDK to add new behavior where we felt the JDK was lacking.

Apart from these utility methods, we've also created some nice wrapper classes that simplify the handling of database access by decorating the JDBC classes. No need to bother with try/catch/finally blocks when checking for open connections or closed result sets. This is taken care of for you. Groovy also provides nice classes for handling JMX remote objects, as if they were local objects. We also have a simple declarative syntax for creating Swing user interfaces very easily. A template engine system lets you create reusable chunks of parameterized text, etc. A lot of attention has been devoted to simplifying the life of the developer.

The last aspect I would like to mention is that the nature of the Groovy language is a bit different from Java. Groovy is a dynamic language: put simply, at runtime, you can intercept method calls, property access, operator calls, etc. This is not possible to do in Java. But in Groovy, it opens the door to a vast field of powerful new constructs. With a malleable syntax, and a dynamic runtime system in which you can hook your own logic, it is possible to create derived languages from Groovy, to let you create Domain-Specific Languages. Languages that are dedicated to a certain task, that represent a certain domain of knowledge, etc. While still being valid Groovy programs, subject matter experts can take control of some parts of your application and help you write complex business logic. This is a very powerful feature that a few dynamic language provides, and Groovy is one of them.

The rigor that Java imposes seems missing in Groovy. For example, in Groovy, one developer may use semi colons while another doesn't. Won't this freedom lead to chaos?

Groovy is almost 4 and a half years old and, so far, nobody has ever complained about this freedom! As your team grows and learns more about Groovy, the style of programming tends to become pretty homogeneous. Everybody tends to adopt the same coding style. It's like the good-old story of aligned or non-aligned curly braces: at some point, you make the decision, as a team, to stick to certain standards, so that it doesn't decrease the readability of the code. So, despite the wider freedom developers have when using Groovy, developers do use it with a lot of care and just love it.

So, because of this connection between Groovy and Java, do you foresee a time when developers will only be using Groovy, and not traditional Java at all?

Everything is possible! After all, if Groovy is becoming even more popular than it is now, and so perhaps more and more developers will want to develop their projects in pure Groovy, without using a single line of Java! I'm pretty confident that Groovy is going to gain even more mindshare and will be used in more and more situations. But I very much like the complementarity of both languages, and I'm sure they will continue to evolve together hand in hand, giving more freedom of choice and more power to the developers.

Are there plans to get Groovy into the JDK?

Good question! As far as I know, there's no concrete plan, neither from Sun Microsystems nor from us, to have Groovy integrated in the JDK. But, obviously, if Sun decided to include Groovy in the JDK, it would be easier for us to help Java developers discover all the great things Groovy has to offer.

The Java platform is really a wonderful platform on which many languages can coexist, and Groovy would definitely be a wonderful complement to Java if it was directly included in the JDK, and then people wouldn't hesitate to mix some Groovy and Java together. Having Groovy in the JDK would definitely ease the adoption of the language.

The sole downside I see to the presence in the JDK would be that, as an Open Source project with its own lifecycle, we would have a bit less freedom in the way we want to make the language evolve over time, and we would have to follow a slower update and improvement cycle. But, as Groovy is pretty mature by now, it may perhaps not be a real problem after all.

What are the three things you are most excited about in Groovy 1.1?

Three things only? Let me give you four, for the same price! First of all, although this is not our own team who did that, I'm so impressed with the work JetBrains did with their JetGroovy plugin for IntelliJ IDEA. This plugin is so powerful! It supports both Groovy and Grails. It offers the usual things such as syntax highlighting, running and debugging of programs, but it even goes further with smart code completion, quick fix light bulbs, and even the main refactorings, such as rename a variable or a method! Those refactorings even work across Groovy and Java! They did a very impressive job, and I suggest that everybody should try this great plugin.

The second thing I'm happy with are all the enhancements that came from the Grails project: new innovative dynamic capabilities have been added to our APIs to simplify the task of creating highly dynamic things in Groovy, thanks to Grails' concept of ExpandoMetaClass. This is a great achievement, and it also shows the symbiotic relationship between the Groovy and the Grails projects.

Thirdly, I just love the support for Java 5 features. We've always wanted to target the most widespread JDK as a runtime platform (1.4 is still pretty common unfortunately), to be sure that everybody could benefit from Groovy, but we felt it was high time that we provided support for things like annotations. So I'm proud that Groovy provides support for these features, allowing developers to fully use their usual enterprise frameworks from Groovy to their fullest extent.

And the last thing which is pretty important to me is all the performance improvements that went into this release. A lot of effort has been made to improve Groovy's performance in those last betas and release candidates. We haven't conducted any serious benchmarking analysis yet, but throughout our different releases, we are used to measuring the time our different test suites are taking. Despite the new tests being added all the time in our test suites (making the suites theoretically longer to run), the overall time was always reduced. It's a good sign for Groovy's raw performance: on the Groovy test suites between 1.1-beta-3 and 1.1-rc-1, we noticed improvements ranging between 15 % to 45 % in execution time, and in the Grails test suites, we noticed an improvement of about 40 % between the usage of Groovy 1.1-rc-1 and 1.1-rc-2.