Justin hat den allgemeinen Fall unten; Ich wollte dieses snippit zeigen zwei Sonderfälle erwähnen:
import java.util.Comparator;
public class WhoCalledMe {
public static void main(String[] args) {
((Comparator)(new SomeReifiedGeneric())).compare(null, null);
new WhoCalledMe().new SomeInnerClass().someInnerMethod();
}
public static StackTraceElement getCaller() {
//since it's a library function we use 3 instead of 2 to ignore ourself
return Thread.currentThread().getStackTrace()[3];
}
private void somePrivateMethod() {
System.out.println("somePrivateMethod() called by: " + WhoCalledMe.getCaller());
}
private class SomeInnerClass {
public void someInnerMethod() {
somePrivateMethod();
}
}
}
class SomeReifiedGeneric implements Comparator<SomeReifiedGeneric> {
public int compare(SomeReifiedGeneric o1, SomeReifiedGeneric o2) {
System.out.println("SomeRefiedGeneric.compare() called by: " + WhoCalledMe.getCaller());
return 0;
}
}
Diese Drucke:
SomeRefiedGeneric.compare() called by: SomeReifiedGeneric.compare(WhoCalledMe.java:1)
somePrivateMethod() called by: WhoCalledMe.access$0(WhoCalledMe.java:14)
Auch wenn die ersten genannt wird „direkt“ von main()
und den zweiten von SomeInnerClass.someInnerMethod()
. Dies sind zwei Fälle, in denen zwischen den beiden Methoden ein transparenter Aufruf erfolgt.
- Im ersten Fall ist dies, weil wir die bridge method auf eine generische Methode aufrufen, die vom Compiler hinzugefügt SomeReifiedGeneric, um sicherzustellen, können als Ausgangstyp verwendet werden.
- Im zweiten Fall ist es, weil wir ein privates Mitglied von WhoCalledMe von einer inneren Klasse aufrufen. Um dies zu erreichen, fügt der Compiler eine synthetische Methode als Vermittler hinzu, um die Sichtbarkeitsprobleme zu überschreiben.
Ich bin immer wieder erstaunt, welche seltsamen Hacks manche Leute "gerne schreiben würden". Nichts für ungut. – delnan
@del Das ist nicht wirklich ein Hack. Es ist im Grunde eine Form der Protokollierung, die wirklich hilfreich sein kann. – jjnguy
ausspionieren .. :-) – DuduAlul