Hi, (I tried sending this mail before, failed so far)
This is about using @CompileStatic inside core Groovy code. The analysis of gradle plugins by Cedric revealed a potential problem with dynamic Groovy: http://melix.github.io/blog/2016/05/gradle-kotlin.html "I think at some point, someone made a terrible design decision in Groovy. I don’t know who it was, but the idea was to rely on exceptions to control the flow of resolution of properties. This means that when a property is missing, typically in a closure, an exception is thrown. When a method is not found, an exception is thrown. When a property is not found, an exception is thrown. That seemed to be a good idea, because in the end, you want to provide the user with an error, but in practice, this is catastrophic, because Groovy can capture those exceptions. Typically, in a delegation chain (nested closures), a containing closure or class can actually have this property defined, or implement property missing/method missing. Now, re-think a second about the "simple" example of Gradle build above: how do you now where to look up for message, top, signature, …? Now you know: f* exceptions are thrown, stack traces are filled, and eventually captured because some composite dynamic object finally wants to answer the message… In practice, for some builds I have profiled, it was tens of thousands of exceptions being thrown and stack traces filled for nothing. And that has a terrible impact on performance." Now I am wondering, since parts of Groovy itself are written in Groovy, and @CompileStatic is not much used in side Groovy itself, does core Groovy suffer from performance issues due to the same reasons as well?
