Lambdas auf bestimmten Schnittstellen beschränken

Question

Angenommen, ich habe ein paar Schnittstellen mit genau einer abstrakten Methode. Nachdem diese Schnittstellen kann ich lambda damit erklären:

interface A { 
    int c(); 
} 

interface B { 
    int c(); 
} 

public class Main { 
    public static void main(String... args) { 
     A a =() -> 42; 
     B b =() -> 42; 
    } 
} 

Kurze Frage: Gibt es einen Trick oder Hack mit Schnittstelle A für Lambda-Ausdrücke zu beschränken und die Build auf Versuch fehlschlagen, dies zu tun? Jeder Hinweis, ob schmutzig oder nicht, ist willkommen (mit 'schmutzig' meine ich Hacks auf Kompilierungs-/Bytecode-Ebene - etwas, das Quellen und vorzugsweise öffentliche Verträge nicht beeinflusst).

Lange Geschichte: für einige Schnittstellen Implementierer halte ich die Definition equals/hashCode als Teil des Vertrages. Außerdem erstelle ich equals/hashCode automatisch für sie zur Erstellungszeit.

In diesem Zusammenhang sind Lambdas Unruhestifter. Für normale und anonyme Implementierer der Schnittstelle A kann ich eine .class Datei und Instrument seinen Bytecode zur Erstellungszeit finden. Für Lambdas gibt es eine VM-anonyme Klasse, die zur Laufzeit erzeugt wird. Das Beeinflussen einer solchen Klasse scheint zur Zeit des Aufbaus unmöglich zu sein, daher muss ich solche Gelegenheiten für bestimmte Schnittstellen zumindest verbieten.

Answer 1

Bitte nehmen Sie sich einen Blick auf meine Lösung dazu:

package com.example.demo; 

public class LambdaDemo { 

    public static void main(String[] args) { 
     //doesn't compile 
     //LambdaRestrictedInterface x =() -> {}; 
     LambdaRestrictedInterface y = new Test(); 
     y.print(); 
    } 

    private static class Test implements LambdaRestrictedInterface { 
     @Override 
     public void print() { 
      System.out.println("print"); 
     } 
    } 

    public interface MyInterface { 
     void print(); 
    } 

    public interface LambdaRestrictedInterface extends MyInterface { 
     @Override 
     default void print() { 
      //hack prevents lambda instantiating 
     } 
    } 
} 

https://dumpz.org/2708733/

Idee ist übergeordnete Schnittstelle mit Standard-impl

Bearbeiten von Absender außer Kraft zu setzen: Nach einiger Überlegung, ich entschied, diese Antwort zu akzeptieren, (da es meinen Bedürfnissen am besten entsprach und ziemlich billig zu implementieren ist) mit einigen formalen Hinzufügungen. Tatsächlich wurde erkannt, dass die minimale Instrumentierung, die genug ist, um zu verhindern, dass die Schnittstelle als Lambda-Typ verwendet wird, einfach eine Standardimplementierung zu ihrer abstrakten Methode hinzufügt.

Answer 2

Von etwas herumspielen, sieht es aus wie das desc Feld des invokedynamic Aufruf enthält die Schnittstelle, die implementiert wird. Zum Beispiel, wenn ich ein einfaches () -> {} Runnable erstellt und übergab es dann durch ASM's Bytecode Outline Plugin, das „ASM-ified“ Aufruf sah aus wie:

mv.visitInvokeDynamicInsn("run", "()Ljava/lang/Runnable;", new Handle...

Also, wenn Sie in der Lage sind, den Build-Zeit-Hack zu tun auf der Aufrufseite (im Gegensatz zur Markierung der Anmerkung selbst als nicht lambda-fähig, was ich nicht glaube, dass Sie tun können), dann sollten Sie in der Lage sein, zuerst eine Reihe von unzulässigen Schnittstellen zu kompilieren, und dann überprüfen Sie die invokedynamic ' s desc gegen diesen Satz.