Zu meinem Teil meiner Antwort auf Should I use Groovy's @CompileStatic if I'm also using Java 7 zu zitieren:
Während schneller als normal Groovy, ist es nur eine Teilmenge von Groovy kompilieren und verhält sich ein bisschen anders. Insbesondere sind alle dynamischen Funktionen nicht mehr verfügbar.
Alle MOP werden umgangen. Builder werden im Allgemeinen nicht funktionieren, einige haben Erweiterungen für den Compiler, damit sie passieren können. Auch Methoden werden zur Kompilierzeit mit statischen Typen ausgewählt, während Groovy normalerweise die zur Laufzeit verfügbaren Methoden und die Laufzeittypen verwendet. Dies kann dazu führen, dass verschiedene Methoden aufgerufen werden.
Natürlich bietet @CompileStatic auch einige Sicherheit, da es die Aufgabe eines Compilers ist, Programme zur Laufzeit zu verifizieren. Aber da statische Informationen unvollständig sind, kann es niemals zu 100% Sicherheit geben.
Also wo ist es ein Kinderspiel ... nun ... POGOs zum Beispiel, da sie normalerweise nicht so viel Code enthalten. Und natürlich für Klassen portiert von Java zu Groovy durch Kopie & Paste.
Wo würde ich es haben wollen? Nun, momentan wohl auf Android, da dort die Code-Größe eine Auswirkung hat und der statische kompilierte Code kompakter ist. Ansonsten geht es mir persönlich gut, wenn ich @CompileStatic überhaupt nicht verwende. Das ist mehr eine Frage des Geschmacks. In einigen Fällen gibt es eine Leistungsverbesserung für enge Schleifen, aber dafür müssen Sie zuerst Ihre Anwendung erstellen und identifizieren.
Klassen, die schneller/typgeprüft werden sollen und keine dynamischen Features benötigen? –