Simulating MixIns with Java
There's always a choice, even if you need some additional state:

You can add the class directly to the class and provide methods for it in the interface or go for your solution.

Adding to the class directly would look like this:

public interface IsBusyMixin {
    boolean isBusy();
    void dumbToggleBusy();

    void overlayTheComponentWithASpinner(); // implement here or not

    void removeTheSpinnerOverlay(); // implement here or not

    public void toggleBusy();
        dumbToggleBusy();
        if (isBusy) {
            overlayTheComponentWithASpinner();
        } else {
            removeTheSpinnerOverlay();
        }
    }
}

public class Foo extends Widget implements IsBusyMixin {
    @Getter private boolean isBusy;
    public void toggleBusy() {
        isBusy = !isBusy();
    }
}


I'd say, it's always somehow possible. However, it may get way uglier then your solution. Moreover, all interface methods must be public and this exposes too much of the inner state.

So when things get a bit more complicated, I wouldn't misuse default methods that hard and would go with your approach instead.

Then you may consider to to use a default method exposing the mixin and maybe another one like

default void toggleBusy() {
    this.mixin().toggleBusy();
}





  Method name overlapping, which is why multiple inheritance is bad (i.e., Widget may have a getSize() method, and IsResizeableMixin may also declare a getSize()). The solution is to give mixin methods distinctive names.


In case one of the methods always delegates to the other, you should probably keep the names the same. Otherwise it can get confusing whatever you do.



The name IsResizeableMixin should probably be just Resizeable or ResizeableMixin.