The @Immutable Annotation
Immutable objects are ones which don't change after initial creation. Such objects are frequently desirable because they are simple and can be safely shared even in multi-threading contexts. This makes them great for functional and concurrent scenarios. The rules for creating such objects are well-known:
- No mutators (methods that modify internal state)
- Class must be final
- Fields must be private and final
- Defensive copying of mutable components
- equals, hashCode and toString implemented in terms of private fields
Writing classes that follow these rules is not hard but does involve a fair bit of boiler plate code and is prone to error. Here is what such a class might look like in Java:
Groovy makes it easier to create such classes using the @Immutable annotation. You only need this:
The "other code" shown above is added at compile time. All of the methods you see above will be there (and you can use them from Java of course). You just don't need to develop and maintain them.
A class created using @Immutable has the following characteristics:
- Properties automatically have private, final backing fields with getters.
- Attempts to update the property will result in a
- A map-based constructor is provided which allows you to set properties by name.
- A tuple-style constructor is provided which allows you to set properties in the same order as they are defined.
toStringmethods are provided based on the property values.
Cloneableobjects and arrays are defensively copied on the way in (constructor) and out (getters).
- Arrays and cloneable objects use the
clonemethod. For your own classes, it is up to you to define this method and use deep cloning if appropriate.
Mapobjects are wrapped by immutable wrapper classes (but not deeply cloned!).
- Attempts to update them will result in an
- Fields that are enums or other
@Immutableclasses are allowed but for an otherwise possible mutable property type, an error is thrown.
- You don't have to follow Groovy's normal property conventions, e.g. you can create an explicit private field and then you can write explicit get and set methods. Such an approach, isn't currently prohibited (to give you some wiggle room to get around these conventions) but any fields created in this way are deemed not to be part of the significant state of the object and aren't factored into the
hashCodemethods. Use at your own risk!