SAM + specialization?

[adriaanm]

The current specialization scheme is not amenable to using
LambdaMetaFactory to spin up subclasses. Since the generic
method is abstract, and the specialized ones are concrete,
specialization is rendered moot because we cannot implement
the specialized method with the lambda using LMF.

For the specialized versions of built-in function types,
we use hand-crafted versions, as illustrated next.
Notice how apply$mcB$sp is looking pretty SAMmy:

@FunctionalInterface
public interface JFunction0$mcB$sp extends JFunction0 {
    @Override
    public byte apply$mcB$sp();

    @Override
    default public Object apply() {
        return BoxesRunTime.boxToByte(this.apply$mcB$sp());
    }
}

Contrast this with our specialized standard FunctionN:

public interface Function0<R> {
    public R apply();

    default public byte apply$mcB$sp() {
        return BoxesRunTime.unboxToByte(this.apply());
    }
}

public interface Function0$mcB$sp extends Function0<Object> { }

The single abstract method in Function0$mcB$sp is apply, and
the method that would let us avoid boxing, if it were abstract,
is apply$mcB$sp...