On 15.12.2017 16:44, mg wrote:
"If we want to keep static Groovy near Java as much as possible..." -
who wants that ? ;-)
ok, scratch the "as possible". As required form a performance and
integration point of view. Doing method calls not the Java way will hurt
performance. Would I for example compile foo.bar() as
if (foo==null) {
NullObject.getInstance().bar()
} else {
foo.bar()
}
then I would really change each and every invocation that is not based
on this or super. The JVM is good at code elimination, but the guard
will be still there, increase the bytecode size and have other effects.
I collected some experience with this kind of logic when implementing
the primitive optimizations.
That is pretty much what I expected. So warning developers about this is
the best thing to do.
yes, static method calls, be it done in Java or static Groovy, are
different than in normal Groovy.
Btw, do we already have an official "@CompileStatic gotchas" section
somewhere ?
I think not. Feel free to add one ;)
bye Jochen
