Pseudo Mixin with Java

When developing in Java I have always been thinking about the possibility to extend more than a class in a straightforward way, with really few code and with the smaller impact in class navigation. Java offer you the ability to extend multiple interfaces and implement them them using the Decorator Pattern, thus giving a simple way to realize a pseudo mixin. It is not too elegant but it is effective:

public interface SayHello { public void hello(); } public class SayHelloImpl { public void hello() { System.out.println("Hello"); } } public class SayThings implements SayWelcome, SayHello { private SayHello sayHello; public SayThings() { sayHello = new SayHelloImpl(); } public void welcome() { System.out.println("Welcome"); } public void hello() { sayHello.hello(); } }

The multi inheritance is provided by encapsulating the implementation of the interface in the SayThings class. So, a quite easy idea but require a good quantity of repetitive code, especially if you have tens of methods. This is worst when it come to implement the pattern for multiple classes. The first idea to solve this was to use our favorite IDE that comes with a decorator helper feature and magically write the code for us. And it is ok until you see that you are still repeating the IDE shortcut a lot, the code growth and growth and you fill like invaded by garbage bridge code. wtf?!

So I come with the idea to generate the code automatically on build time. I was inspired by Liferay's feature to build services in an automated way generating the code from a template. Searching for an easy way to generate my decorations but with the option to not modify the bytecode nor using dynamic proxy (like Spring IoC). I wanted native crystalline code that was there for debug and readability but confined in a separate folder from "real" code and not saved in the repo.

The solution need to be also easy to use in Maven and Eclipse. Maven gives you the ability to develop plugins that add funcionality to the lifecycle of the software and also they can integrate directly into Eclipse (or our other favorite IDE ^^). Even if there is not much docu it is possible to find quite a lot of examples in the Web on how to implement a plugin that permit code generation and also is Eclipse friendly.

The resulte are quite awesome to me, and this is what my "tiny" lib allow to do:

@MixinType(impl=SayHelloImpl.class) public interface SayHello { public void hello(); } public class SayHelloImpl { public void hello() { System.out.println("Hello"); } } @GeneratedMixin public abstract class SayThings implements SayWelcome, SayHello { public void welcome() { System.out.println("Welcome"); } }

Even if the code dosen't seem too synthetic it actually remove the need to write the implemented function(s) since the class is abstract (though it permit to overwrite the behaviour). The code generator create a class that extend this abstract and implement unimplemented methods using the interface annotation as an hint. The annotation on the abstract class is used by the maven plugin to generate and compile the code. To instantiate this Mixin the class MixinFactory is used:

SayThings sayThings = MixinFactory.create(SayThings.class);

The factory search for the implementation class (that could have been yet generated and compiled) using a specific pattern. That is by the fully qualified name of the abstract class preceded by the package org.codequake.core.mixin. If not found it try to generate the implementation and compile it in memory if the JVM provide a compiler. In other word it compile the implementation if the method javax.tools.ToolProvider.getSystemJavaCompiler() does not return null.

Someone could say this is not Mixin it is an auto decorator facility. But in the end I decided to prefix all classes with the short Mixin word. So blame me for that! >:)

Anyway in a moment of doubt I documented myself a bit more and changed the parts of the blog post (including the title ^^) that were using the word "Mixin" with a more correct "Pseudo Mixin".