GEP-22

Single inheritance forces all reuse through a single line, leading to deep hierarchies, fragile base-class problems, and inability to mix unrelated capabilities.

Java 8 default methods attach behaviour to interfaces but are stateless by design, do not support stackable composition through super, and their resolution rules are designed around binary compatibility rather than composition.

Runtime mixins (Groovy’s pre-2.3 @Mixin annotation, since deprecated) weave behaviour at runtime but the resulting object is not an instanceof the mixed-in type, defeating type-based dispatch and compile-time checks.

Delegation via @Delegate expresses has-a relationships well but is verbose for genuine is-a composition and does not support overriding delegated behaviour transparently.

Public and private methods are supported. protected and package-private are not supported.

Abstract methods are permitted; concrete classes that implement the trait must provide an implementation unless they too are abstract.

Private methods do not appear on the generated trait interface and are not visible to other classes.

The final modifier records the intended modifier of the woven method in the implementing class. Mixing final and non-final declarations of the same signature across multiple inherited traits is permitted; normal trait method-selection rules apply and the resulting method takes the modifier of the selected source.

For a field bar of type T declared in trait my.pkg.Foo, the implementing class gains a field named my_pkg_Foo__bar of type T.

The mangling rule is: replace each . in the package name with , append <TraitSimpleName>__<fieldName>. The double underscore separates the trait identity from the field identity.

Private fields follow the same scheme but are also marked private; the mangling guarantees no collisions when a class implements multiple traits that declare fields of the same name (the diamond problem for state).

by providing its own implementation of the method, or

by calling T.super.m(…​) for the desired trait T.

implements SomeTrait (or TraitA and TraitB),

implements every interface that the original object implemented, and

delegates to the original object for behaviour not supplied by the applied trait(s).

Each implementing class receives its own copy of static members. Static state is not shared across implementing classes — a static field declared in a trait is conceptually a template, instantiated per implementer.

Static members are not exposed on the generated trait interface. Calls of the form Trait.staticMethod(…​) are not statically valid.

Static members are accessed dynamically and are not subject to static type checking; traits with static methods cannot be @CompileStatic.

Mixing static and instance methods of the same signature across multiple traits is undefined behaviour and should be avoided. If selection chooses a static variant where an instance variant is required, a compilation error is raised; conversely, an instance selection silently shadows the static variant.

@SelfType constrains what an implementing class must already be (its supertype shape).

@Sealed constrains which specific classes are allowed to implement the trait at all.

AST transform compatibility is best-effort. Some transforms (@CompileStatic, @TypeChecked, logging transforms) apply cleanly to traits; others apply only to the implementing class; others are unsupported. New transforms should be evaluated case by case.

Prefix and postfix operators (+`, `--`) on a trait field are rejected at compile time. The workaround is `= / -=. The reason is that the field-helper indirection cannot represent the read-modify-write sequence atomically.

Constructors on traits are not supported. Initialisation logic should be expressed via abstract methods supplied by the implementing class, or via property defaults.

Inheritance-of-state gotcha: trait method bodies that read a trait field directly read the trait’s own field, not any same-named property declared by the implementing class. To pick up an overriding value, trait code should access state through accessors (getX()), not by direct field reference.

TraitASTTransformation — entry point invoked for every trait declaration; produces the interface, helper, field-helper and (where applicable) static-field-helper artefacts.

TraitComposer — weaves trait methods, accessors and bridge methods into each implementing class.

TraitReceiverTransformer — rewrites references inside trait method bodies so that this, super and field accesses resolve to the implementing-instance receiver and to helper-routed state.

Traits — utility class holding helper-class naming constants ($Trait$Helper, $Trait$FieldHelper, $Trait$StaticFieldHelper), trait detection predicates, and self-type collection logic.

TraitTypeCheckingExtension — integrates traits with the static type checker (GEP-8).

groovy.transform.Trait (since 2.3.0)

groovy.transform.SelfType (since 2.4.0)

GROOVY-7134: introduce @SelfType for statically checked traits.

GROOVY-8233: Java stub generation for static properties of traits.

GROOVY-8299: native default/private/static methods in interfaces (decoupling from trait machinery in 5.0).

GROOVY-8219, GROOVY-8788: @TupleConstructor interaction with traits and default values.

GROOVY-8951: trait getter conflicts with generated getter (pre-compiled case).

GROOVY-11674: deterministic ordering of trait methods for reproducible builds.

GROOVY-11907: trait field reference transform restructure.