Java 8: Now You Have Mixins?

Java 8 starts to emerge. It comes with a full new feature: functional programming with the lambda expressions. Here I’ll discuss about a feature that is part of the Lambda project (JSR-335): the virtual extension methods, also called public defender methods. This feature will help you to provide a default implementation for the methods that you have declared in your interfaces. This allows, for example, the Java team to add method declarations in existing interfaces, like List or Map. On their side, the developers do not need to redefine their different implementations in Java libraries (like Hibernate). Thus, Java 8 will be theoritically compatible with existing libraries.

The virtual extension methods are a way to provide multiple inheritance in Java. The team who works on Lambda project argues that the kind of multiple inheritance provided with virtual extension methods is limited to behaviour inheritance. As a challenge, I show that with virtual extension methods, you can also emulate state inheritance. To do so, I describe in this article an implementation of mixin in Java 8.

What a mixin is?

The mixins are kind of composable abstract classes. They are used in a multi-inheritance context to add services to a class. The multi-inheritance is used to compose your class with as many mixins as you want. For example, if you have a class to represent houses, you can create your house from this class and extend it by inheriting from classes like Garage and Garden. Here is this example written in Scala:

val myHouse = new House with Garage with Garden

To inherit from a mixin is not really a specialization. It is rather a mean to collect functionalities and add them to a class. So, with mixins, you have a mean to do structural factorization of code in OOP and to enhance the readability of classes.

For example, here is a use of mixins in Python in the module socketserver. Here, the mixins help to declare four socket based servers: a UPD and a TCP services using multi-processes, a UPD and a TCP services using multi-threading.

class ForkingUDPServer(ForkingMixIn, UDPServer): pass
class ForkingTCPServer(ForkingMixIn, TCPServer): pass

class ThreadingUDPServer(ThreadingMixIn, UDPServer): pass
class ThreadingTCPServer(ThreadingMixIn, TCPServer): pass

What are virtual extension methods?

Java 8 will introduce the notion of virtual extension method, also called public defender method. Let’s called them VEM.

A VEM aims to provide a default implementation for a method declared in a Java interface. This helps to add a new method declaration in some widely used interfaces, like the interfaces of the JDK’s Collection API. Thus, all the existing libraries like Hibernate that reimplements the Collection API do not need to rewrite their implementation, because a default implementation is provided.

Here is an example of how you will declare a default implementation in an interface:

public interface Collection<T> extends Iterable<T> {

    <R> Collection<R> filter(Predicate<T> p)
        default { return Collections.<T>filter(this, p); }

}

A naive emulation of mixin in Java 8

Now, we will implement a mixin by using the VEMs. But I have to warn you first: Please, don’t use it at work! Seriously, DON’T USE IT AT WORK!

The implementation below is not thread-safe, subject to memory leak, and completely depends on the way you have defined hashCode and equals in your classes. There is another major drawback that I will discuss later.

First, we define an interface with a default implementation that seems to be based on a stateful approach.

public interface SwitchableMixin {

    boolean isActivated() default { return Switchables.isActivated(this); }

    void setActivated(boolean activated) default { Switchables.setActivated(this, activated); }

}

Second, we define a utility class that owns a map to store associations between the instances of our previous interface and their state. The state is represented by a private nested class in the utility class.

public final class Switchables {

    private static final Map<SwitchableMixin, SwitchableDeviceState> SWITCH_STATES = new HashMap<>();

    public static boolean isActivated(SwitchableMixin device) {
        SwitchableDeviceState state = SWITCH_STATES.get(device);
        return state != null && state.activated;
    }

    public static void setActivated(SwitchableMixin device, boolean activated) {
        SwitchableDeviceState state = SWITCH_STATES.get(device);
        if (state == null) {
            state = new SwitchableDeviceState();
            SWITCH_STATES.put(device, state);
        }
        state.activated = activated;
    }

    private static class SwitchableDeviceState {
        private boolean activated;
    }

}

Here is a use case for the implementation above. It highlights the inheritance of the behavior and of the state.

private static class Device {}

private static class DeviceA extends Device implements SwitchableMixin {}

private static class DeviceB extends Device implements SwitchableMixin {}

DeviceA a = new DeviceA();
DeviceB b = new DeviceB();

a.setActivated(true);

assertThat(a.isActivated()).isTrue();
assertThat(b.isActivated()).isFalse();

“And Now for Something Completely Different”

This implementation seems to work well. But Brian Goetz, the Oracle’s Java Language Architect, has suggested me a puzzle where the current implementation does not work (assuming thread-safety and memory leak are fixed).

interface FakeBrokenMixin {
    static Map<FakeBrokenMixin, String> backingMap
        = Collections.synchronizedMap(new WeakHashMap<FakeBrokenMixin, String>());

    String getName() default { return backingMap.get(this); }
    void setName(String name) default { backingMap.put(this, name); }
}

interface X extends Runnable, FakeBrokenMixin {}

X makeX() { return () -> { System.out.println("X"); }; }

    X x1 = makeX();
    X x2 = makeX();
    x1.setName("x1");
    x2.setName("x2");

    System.out.println(x1.getName());
    System.out.println(x2.getName());

Can you guess what this should display?

Solution to the puzzle

At first sight, there seems to be no problem with this implementation. There, X is an interface with a single method, because the method getName and setName have a default implementation and not the method run from Runnable. So we can generate an instance of X from a lambda expression, that will provide an implementation to the method run, as the method makeX does. So, you expect that this program displays something like:

x1
x2

If you remove the calls to getName, you expect to display something like:

MyTest$1@30ae8764
MyTest$1@123acf34

Where the two lines indicates that makeX produces two separate instances. And this what the current OpenJDK 8 produces (here I have used the OpenJDK 8 24.0-b07).

However, the current OpenJDK 8 does not reflect the eventual behavior of Java 8. To do so, you need to run javac with the special option -XDlambdaToMethod. Here is the kind of output you get once the special option is used:

x2
x2

If you remove the calls to getName, you will get something like:

MyTest$$Lambda$1@5506d4ea
MyTest$$Lambda$1@5506d4ea

Each call to makeX seems to give a singleton instantiated from the same anonymous inner class. Nevertheless, if you look at the directory holding the Java binaries (having carefully removed all *.class files before), you will not find a file named MyTestClass$$Lambda$1.class.

The complete translation of the lambda expression is not really done at compile time. In fact, this translation is done at compile time and runtime. The compiler javac put in place of lambda expression an instruction recently added to JVM : the instruction invokedynamic (JSR292). This instruction comes with all the necessary meta-information to the translation of the lambda expression at runtime. This includes the name of the method to call, its input and output types, and also a method called bootstrap. The bootstrap method aims to define the instance that receive the method call, once the JVM execute the instruction invokedynamic. In presence of lambda expression the JVM uses a particular bootstrap called lambda metafactory method.

To come back to the puzzle, the body of the lambda expression is converted into a private static method. Thus, () -> { System.out.println("X"); } is converted in MyTest into

private static void lambda$0() {
    System.out.println("X");
}

This can be seen if you use the decompiler javap with the option -private (you can even use the -c option to see the more complete translation).

When you run the program, once the JVM tries to interpret the invokedynamic instruction for the first time, the JVM call the lambda metafactory method, describes above. In our example, during the first call to makeX, the lambda metafactory method generates an instance of X and links the method run (from the interface Runnable) dynamically to the method lambda$0. The instance of X is then stored in the memory. During the second call to makeX, the instance is brought back. There you get the same instance as during the first call.

Fix? Workaround?

There is no direct fix or workaround for this problem. Even if it is planned to activate -XDlambdaToMethod by default for Oracle’s Java 8, this is not supposed to appear in the JVM specification. This kind of behavior might change over the time and among vendors. For a lambda expression, what you can only expect is to get something that implements your interface.

Another approach

So our emulation of mixins is not compatible with Java 8. But there is still a possibility to add services to an existing class by using multiple inheritance and delegation. This approach is referenced as virtual field pattern.

So lets start again with our Switchable.

interface Switchable {    boolean isActive();
    void setActive(boolean active);
}

We need an interface based on Switchable with an additional abstract method that returns an implementation of Switchable. The inherited methods get a default implementation: they use the previous getter to transmit the call to the Switchable implementation.

public interface SwitchableView extends Switchable {
    Switchable getSwitchable();


    boolean isActive() default { return getSwitchable().isActive(); }
    void setActive(boolean active) default { getSwitchable().setActive(active); }
}

Then, we create a complete implementation of Switchable.

public class SwitchableImpl implements Switchable {


    private boolean active;


    @Override
    public boolean isActive() {
        return active;
    }


    @Override
    public void setActive(boolean active) {
        this.active = active;
    }
}

Here is an example where we use the virtual field pattern.

public class Device {}


public class DeviceA extends Device implements SwitchableView {
    private Switchable switchable = new SwitchableImpl();


    @Override
    public Switchable getSwitchable() {
        return switchable;
    }
}


public class DeviceB extends Device implements SwitchableView {
    private Switchable switchable = new SwitchableImpl();


    @Override
    public Switchable getSwitchable() {
        return switchable;
    }
}

DeviceA a = new DeviceA();DeviceB b = new DeviceB();

a.setActive(true);

assertThat(a.isActive()).isTrue();
assertThat(b.isActive()).isFalse();

Conclusion

In this post, we have seen two approaches to add services to a class in Java 8 with the help of virtual extension methods. The first approach uses a Map to store instance states. This approach is hazardous for more than one reason: it can be not thread-safe, there is a risk of memory leaks, it depends on the way your vendor has implemented the language, etc. Another approach, based on delegation and referenced as virtual field pattern, uses an abstract getter and let the final implementation describes which implementation of a service it uses. This last approach is more independent from the way the language is implemented and more secure.

The virtual extension method is something new in Java. It brings another mean of expression to create new patterns and best pratices. This article provides an example of such a pattern, enabled in Java 8 due to the use of virtual extension methods. I am sure you can extract other new patterns from them. But, as I have experienced here, you should not hesitate to share them in a view to check their validaty.

EDIT: after sharing in the lambda project mailing list, some modifications has needed to be reported in this post, in a view to reflect the new behavior of Java 8. Thank to Brian Goetz from Oracle and Yuval Shavit from Akiban for their suggestions.

• [2012-07-11] changed title + renamed “How to emulate mixin in Java 8?” to “Naive emulation of mixin in Java 8” + added a puzzle
• [2012-07-12] added a section + removed the conclusion
• [2012-07-22] added the solution to the puzzle
• [2012-07-24] added fix/workaround section + some correction
• [2012-08-13] completed all sections

Towards Pattern Matching in Java

Pattern matching is such a cool feature that you always dream of in your language to represent alternative structures. It already exists in OCaml, in Haskell, or in Scala (here is an post in this blog showing the different usages of the pattern matching in Scala: Playing with Scala’s pattern matching). In Java, what is almost closed to pattern matching is named switch-case. But, you’re limited to scalar values (chars, integer types, booleans), enum types, and since Java 7 you can use strings. With the Java’s switch-case, you don’t have a way to check the type of arguments or to really mix the different kind of check, for example. These are features that pattern matching provides.

In this post, we’ll study a possibility to get an implementation in Java close to pattern matching. We’ll use lambda expressions of Java 8 in a view to get a more readable structure. Here, I don’t propose to make a real pattern matching, but to get a structure that can match different kinds of patterns and which is more flexible than the traditional switch-case.

Main implementation

First, we need a PatternMatching class. This class is a set of Pattern instances. Each Pattern can check if a value matches (a pattern) and is bound to a process/function that it can apply on.

The class PatternMatching provides just the method matchFor. This method tests the different Pattern instances that it contains to a value. If a Pattern matches, the method matchFor is applied to the value the function bound to the Pattern. If no pattern has been found, the method throws an exception.

To instantiate this class, you’ll need to provide a set of patterns.

public class PatternMatching {
    private Pattern[] patterns;

    public PatternMatching(Pattern... patterns) { this.patterns = patterns; }

    public Object matchFor(Object value) {
        for (Pattern pattern : patterns)
            if (pattern.matches(value))
                return pattern.apply(value);

        throw new IllegalArgumentException("cannot match " + value);
    }
}

Pattern

Pattern is an interface that provides two methods. matches should check if an object meets some requirements. apply should execute a process on a object. apply should be called once matches succeeded.

public interface Pattern {
    boolean matches(Object value);
    Object apply(Object value);
}

A first Pattern example: pattern for types

For example, ClassPattern is a Pattern implementation that checks the type of a value.

public class ClassPattern<T> implements Pattern {

    private Class<T> clazz;

    private Function<T, Object> function;

    public ClassPattern(Class<T> clazz, Function<T, Object> function) {
        this.clazz = clazz;
        this.function = function;
    }

    public boolean matches(Object value) {
        return clazz.isInstance(value);
    }

    public Object apply(Object value) {
        return function.apply((T) value);
    }

    public static <T> Pattern inCaseOf(Class<T> clazz, Function<T, Object> function) {
        return new ClassPattern<T>(clazz, function);
    }
}

Take a look at the example below:

PatternMatching pm = new PatternMatching(
    inCaseOf(Integer.class, x -> "Integer: " + x),
    inCaseOf(Double.class, x -> "Double: " + x)
);

System.out.println(pm.matchFor(42));
System.out.println(pm.matchFor(1.42));

This code displays:

Integer: 42
Double: 1.42

Usual patterns

Here are some “usual patterns”, in the sense that they imitate some functionality you already have with switch-case. First, we start with the pattern to match strings:

public class StringPattern implements Pattern {
    private final String pattern;
    private final Function<String, Object> function;

    public StringPattern(String pattern, Function<String, Object> function) {
        this.pattern = pattern;
        this.function = function;
    }

    @Override
    public boolean matches(Object value) { return pattern.equals(value); }

    @Override
    public Object apply(Object value) { return function.apply((String) value); }

    public static Pattern inCaseOf(String pattern, Function<String, Object> function) {
        return new StringPattern(pattern, function);
    }
}

Now, here is a pattern to match integers:

public class IntegerPattern implements Pattern {
    private final Integer pattern;
    private final Function<Integer, Object> function;

    public IntegerPattern(int pattern, Function<Integer, Object> function) {
        this.pattern = pattern;
        this.function = function;
    }

    @Override
    public boolean matches(Object value) { return pattern.equals(value); }

    @Override
    public Object apply(Object value) { return function.apply((Integer) value); }

    public static Pattern inCaseOf(int pattern, Function<Integer, Object> function) {
        return new IntegerPattern(pattern, function);
    }
}

And to finish, here is a pattern that matches everything. It is the equivalent of default in switch-case.

public class OtherwisePattern implements Pattern {
    private final Function<Object, Object> function;

    public OtherwisePattern(Function<Object, Object> function) {
        this.function = function;
    }

    @Override
    public boolean matches(Object value) { return true; }

    @Override
    public Object apply(Object value) { return function.apply(value); }

    public static Pattern otherwise(Function<Object, Object> function) {
        return new OtherwisePattern(function);
    }
}

Now, you can express something like this:

PatternMatching pm = new PatternMatching(
    inCaseOf(Integer.class, x -> "Integer: " + x),
    inCaseOf(      "world", x -> "Hello " + x),
    inCaseOf(           42, _ -> "forty-two"),
    otherwise(              x -> "got this object: " + x.toString())
);

Factorial based on PatternMatching

Our pattern matching API in Java 8 can define the body of recursive functions:

public static int fact(int n) {
    return ((Integer) new PatternMatching(
            inCaseOf(0, _ -> 1),
            otherwise(  _ -> n * fact(n - 1))
    ).matchFor(n));
}

Here, we use the lambda expressions to improve the readability. In this case, Java 8 is necessary. But it is easy to use the implementations of PatternMatching and Pattern above with former versions of Java. Nevertheless, you have to sacrify the readability.

For example, here is the implementation of the same factorial function for versions 6 and 7 of Java:

public static int fact_old(final int n) {
    return ((Integer) new PatternMatching(
            inCaseOf(0, new Function<Integer, Object>() {
                @Override
                public Object apply(Integer _) {
                    return 1;
                }
            }),
            otherwise(new Function<Object, Object>() {
                @Override
                public Object apply(Object _) {
                    return n * fact(n - 1);
                }
            })
    ).matchFor(n));
}

Conclusion

In this post, we’ve seen a way to define a structure close to pattern matching. This structure helps us to extend the semantic of switch-case in Java. Besides, it’s extendable with new implementations based on Pattern. The use of the Java 8’s lambda expressions make it more readable.

Nevertheless, if a PatternMatching is defined in a method, it’ll be completely reinstantiated at each call of this method. But if performance is needed, you can store the pattern matching in a constant.

So, we are able to represent pretty much the same functionnality than switch-case. The usual patterns I haven’t presented can be easily implemented. In addition, we can find a way to do pattern matching based on regular expressions. What is missing here is the ability to aggregate a set of patterns to the same process (ie. a kind of OR relation between some patterns for the same process), the addition of guard condition and above all the ability to represent algebraic types and use them in our structure.

From Option to Monad with Java Only

In a previous post, I’ve shown how to use the type Optional provided by Guava, in a view to create a monad. Personally, I’m not satisfied with the resulting code. Since, I’ve found another way to represent the Option monad in Java only, and the new representation seems to be better.

So we start with an interface to represent functions (this is the same as the Guava).

public interface Function<T, R> {
  R apply(T input);
}

Then we implement the Option type. This type contains three monadic operations :

• wrap that converts an object into an Option,
• andThen that applies a function to the current instance of Option,
• fail that returns a None instance.

I add also two getter methods : get and isPresent.

public abstract class Option<T> {

  // opérations de base

  public abstract T get();

  public abstract boolean isPresent();

  // opérations monadiques

  public static <T> Option<T> wrap(T element) { return new Some<T>(element); }

  public static <T> Option<T> fail() { return new None<T>(); }

  public abstract <U> Option<U> andThen(Function<T, Option<U>> function);

}

And now, here is the implementation of the classes Some and None.

public class None<T> extends Option<T> {

  public T get() { throw new IllegalStateException(); }

  public boolean isPresent() { return false; }

  public <U> Option<U> andThen(Function<T, Option<U>> function) {
    return new None<U>();
  }

}

public class Some<T> extends Option<T> {

  private T element;

  private Some(T element) { this.element = element; }

  public T get() { return element; }

  public boolean isPresent() { return true; }

  public <U> Option<U> andThen(Function<T, Option<U>> function) {
    return function.apply(this.element);
  }

}

To come back to the example of the previous post, here are implementations of the different accessors that enables you to explore the (ugly) recursive structure made of Java Maps representing a set of products arranged according to their supplier, city, and country:

public static Function<
  Map<String, Map<String, Map<String, Map<String, Product>>>>,
  Option<Map<String, Map<String, Map<String, Product>>>>
>
accessCountry(String country) {
    return getFromKey(country);
}

public static Function<
  Map<String, Map<String, Map<String, Product>>>,
  Option<Map<String, Map<String, Product>>>
>
accessCity(String city) {
    return getFromKey(city);
}

public static Function<
  Map<String, Map<String, Map<String, Product>>>,
  Option<Map<String, Map<String, Product>>>
>
accessCity(String city) {
    return getFromKey(city);
}

public static Function<
  Map<String, Map<String, Product>>,
  Option<Map<String, Product>>
>
accessSupplier(String supplier) {
    return getFromKey(supplier);
}

public static Function<
  Map<String, Product>,
  Option<Product>
>
accessProduct(String productCode) {
    return getFromKey(productCode);
}

Here is the definition of the method getFromKey:

public static <K, V> Function<Map<K, V>, Option<V>> getFromKey(final K key) {
    return new Function<Map<K, V>, Option<V>>() {
        @Override
        public Option<V> apply(Map<K, V> map) {
            V value = map.get(key);
            if (value == null) {
                return Option.none();
            }
            return Option.wrap(value);
        }
    };
}

Now look how the method getProductFrom is simplified:

public Option<Product> getProductFrom(
  Map<String, Map<String, Map<String, Map<String, Product>>>> productsByCountry,
  String country, String city, String supplier, String code) {

  return wrap(productsByCountry)
    .andThen(accessCountry(country))
    .andThen(accessCity(city))
    .andThen(accessSupplier(supplier))
    .andThen(accessProduct(code));
}

But I cheating a little bit with the way monads are usually used. Normally, a succession of process calls within a monad isn’t a linear chaining like in the example above, but a kind of recursive chaining. I can get such a chaining (without the ugliness of the Java verbosity) if I use the lambda expression of Java 8.

public Option<Product> getProductFrom(
  Map<String, Map<String, Map<String, Map<String, Product>>>> productsByCountry,
  String country, String city, String supplier, String code) {

  return getFrom(productsByCountry, country).andThen(
         cities -> getFrom(cities, city).andThen(
         suppliers -> getFrom(suppliers, supplier).andThen(
         products -> getFrom(products, code))));
}

public <K, V> Option<V> getFrom(Map<K, V> map, K key) {
  V value = map.get(key);
  if (value == null) {
    return Option.none();
  }
  return Option.wrap(value);
}

As a remainder, the construct x -> f(x) currently defines a lambda expression in Java 8.