2015-05-15 12 views
16

Hier ist mein Beispiel Java-Code:Eklipse - `offener Aufruf hierarchy` zu stoppen in lambda-Kette Suche

public class Test { 

    public static void main(String[] args) { 
     methodDepth0(
      ()-> 
       methodDepth1(
        ()-> 
         methodDepth2() 
       ) 
     ); 
    } 

    static Object methodDepth2() { 
     return null; 
    } 

    interface MyIF { 
     void call(); 
    } 

    static void methodDepth0(MyIF myIf){ 
     myIf.call(); 
    } 

    interface MyIF2 { 
     void call(); 
    } 

    static void methodDepth1(MyIF2 myIf2){ 
     myIf2.call(); 
    } 
} 

Wenn ich öffne Aufrufhierarchie Methode methodDepth2() von Eclipse-(4.4), open call hierarchy Stopp nächste Anrufer suchen: open call hierarchy stop searching next caller method

Was ich erwarte, ist wie Aufrufhierarchie Methode methodDepth1() Öffnung, die bis zum main Verfahren zeigen. opening call hierarchy of method <code>methodDepth1()</code> which show until the <code>main</code> method

+0

Ein schneller Patch: https://goo.gl/2R0xH4 – andyf

Antwort

2

Von dem, was ich sagen kann, ist der Mangel an Call-Hierarchie-Tiefe aufgrund (Neu-) Evaluierung von Code zur Laufzeit. Es wird in 15.27.4 Run-Time Evaluation of Lambda Expressions in der Java Language Specification erläutert.

Während der Laufzeit ähnelt die Auswertung eines Lambda-Ausdrucks der Auswertung eines Klassenexemplar-Erstellungsausdrucks, sofern die normale Vervollständigung einen Verweis auf ein Objekt erzeugt. Die Auswertung eines Lambda-Ausdrucks unterscheidet sich von der Ausführung des Lambda-Körpers.

0

als das zweite Bild zeigt deutlich, Eclipse-ist Lage, die Aufrufhierarchie durch den Methodenaufruf myIf.call() innen methodDepth0 zu verfolgen. Das ist richtig, weil das (äußere) Lambda die Methode MyIF.call() implementiert.

Die Tatsache, dass das gleiche Muster in der nächsten Verschachtelungsebene nicht funktioniert, sieht wie ein Fehler aus. Bitte beachten Sie filing a bug für JDT/UI. TIA.

Es genügt bemerken, dass für lambdas Umsetzung Bibliothekstypen wie Consumer<T>, die Anzahl der Anrufer in accept(T) in einem Arbeitsbereich leicht unüberschaubar kann, ähnlich wie bei jeder Aufrufhierarchie durch zB Runnable.run() - aber das nicht in Frage stellt die allgemeine Nützlichkeit von Call-Hierarchien durch Lambdas.

+0

Vielen Dank, ich hatte diesen Bug gefüllt: https://bugs.eclipse.org/bugs/show_bug.cgi?id=468561 – andyf