Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »





Static Type Checking








Cédric Champeau



Last modification:


Abstract: Static Type Checking

This GEP introduces a new feature in the language known as static type checking. It is often disturbing for developers coming from a statically typed language (say Java) to discover that the Groovy compiler will not complain at compile time:

  • when assignments are made on different types
  • when a method doesn't exist
  • when a property or variable doesn't exist
  • when returned object type doesn't match the method signature
  • ...

All those are silent because the dynamic nature of the Groovy language makes such code perfectly valid. However, in some situations, a developper may want Groovy to behave like a statically typed language and have the compiler give hints about such "errors". To do this, Groovy must introduce static type checking.

Rationale: Static Type Checking vs Static compilation

It is important to make the difference between static type checking and static compilation. The goal of this GEP is to have an option to turn static type checking (STC) on. If STC is activated, the compiler will be more verbose (you will also see the term "grumpy"), but in the end, the generated bytecode and runtime behaviour will be exactly the same as if you did not activate this mode. This is a major difference from an alternate compiler like Groovy++ which will perform STC then produce a different bytecode and therefore produce different runtime semantics. The scope of this GEP is only a static type checker, and therefore should only be considered as a feature which allows developers to write statically checked code, so is an elegant way for example to leverage the Groovy syntax to reduce verbosity of Java code while still getting strongly checked code. Eventually, IDE could support the STC mode and provide information to the developper.

Implementation details

Development branch

The code is currently in heavy development, so make sure that you checkout the code from Git. The code is in the grumpy branch. It adds an AST transformation named StaticTypes. If set, then the AST transformation will perform type inference and store type information in AST nodes metadata. Eventually, if errors are found, it will add errors to the compiler through a dedicated addStaticTypeError method which basically does the same as the traditional addError method but prefixes the messages with a "Static type checking" message. This is done to help the developer determine whether the error he is seeing is a "plain Groovy" error, or an error thrown by the STC mode.

The StaticTypeCheckingTestCase class

Static type checking behaviour must be tested. As there are tons of possible checks to be done, a base test class provides a framework for testing this mode. Unit tests for static type checking should override this class.

Decisions made

About this section

The goal of this section is to provide code samples which demonstrates in what case the STC transformation will actually complain and what is the expected error message, and serves as a basis to future STC documentation. This section may not be up-to-date, and one should always take a look at the STC unit tests found in the src/test/groovy/transform/stc directory.

Open discussions

What to do on assignment

See the discussion on the mailing list. Here we must discuss what to do in those situations :


Java behaviour

Suggested behaviour for STC

Complains about possible loss of precision

"Standard Groovy" actually performs an implicit cast : int y=(int)x. So there is normally no reason to complain. However, it can be disturbing for the Java developer and may be a source of error.


Should not complain


Should not complain

Unification Types

In cases of for example "x instanceof A || x instanceof B" with A and B being unrelated we could still make an artificial union kind of type, that contains everthing present in A and B, to allow those kinds of method calls. The alternative to this is to allow only methods from Object here, which is less interesintg. This typing can also be used for multicatch, ensuring that a method call is only valid if it exists on each of the exceptions for the multicatch. In the current implementation (Okt-14-2011) the multicatch is already expanded at the point @StaticTypes will check. Meaning effectively this already represents a kind of union type, as the same code is in each catch block and thus the method call would fail, if the method is not available on each type. The proposed behaviour is therefore to align the instanceof case with multicatch.


Mailing-list discussions

JIRA issues

  • No labels