UPDATE: Qi4j is now Apache Polygene, https://polygene.apache.org
Qi4j's definition of Mixins are probably quite unique, as it doesn't start with a base class. By going to that extreme, a whole new paradigm of how applications are built up emerges, and we call that Composite Oriented Programming. The Composite is the 'object' equivalent and not only are Mixins wired together, but also Constraints (validation), Concerns (around advice) and SideEffects (can't alter the method outcome).
So I think Qi4j has a very strong Mixin story to tell. Mixins can be 'typed' or 'generic', they can be public (accessible outside the composite) or purely private (within the Composite). Qi4j strongly defines what Properties are, and goes on to have built-in persistence, which doesn't leak the storage implementation into your domain (caveat; Qi4j leaks to your domain). And once persisted entities enters the picture, strong definition of a Associations are also required (and included in Qi4j).
See http://www.qi4j.org/state-modeling.html for a good overview.
In Qi4j, ONLY Mixins have state. Constraints/Concerns/SideEffects can't have state (if they do they need to referens a private mixin).
To define a composite in Qi4j, it is possible to either do it structurally on the types themselves, OR at bootstrap time when the runtime model is created.
Structurally;
@Mixins({PetrolEngfineMixin.class, FourWheelsMixin.class})
public interface Car extends HasEngine, HasWheels, EntityComposite
{}
At boot time;
public interface Car
{}
public class CarModuleAssembler
implements Assembler
{
public void assemble( ModuleAssembly module )
{
module.entities( Car.class )
.withMixins( PetronEngineMixin.class, FourWheelsMixin.class );
}
}
Yet, this is just touching on the surface of the features in Qi4j.
