"If we want to keep static Groovy near Java as much as possible..." - who wants that ? ;-) That is pretty much what I expected. So warning developers about this is the best thing to do. Btw, do we already have an official "@CompileStatic gotchas" section somewhere ? Cheers,mg
-------- Ursprüngliche Nachricht --------Von: Jochen Theodorou <blackd...@gmx.org> Datum: 15.12.17 16:34 (GMT+01:00) An: users@groovy.apache.org Betreff: Re: @CompileStatic null iteration Am 15.12.2017 um 14:35 schrieb Winnebeck, Jason: > It’s been like this for as long as I’ve been using compile static in > Groovy. I assumed that was expected behavior and I make sure to point it > out to all new developers in our project as one of the Groovy gotchas. > Is it not supposed to be that way? Afaik it is supposed to be this way for technical reasons Not failing invocation on null means to not be able to use direct method calls in static compiled code. And while they do not have to be as dynamic as in standard Groovy, you would have to make them at least with invokedynamic. And that is because if I tell the JVM to invoke String#length(), it does not like to get NullObject instead of a String. in summary: If we want to keep static Groovy near Java as much as possible, we pay this for example with the NPE here. bye Jochen
