groovy/groovy-core — pull request #552 by donnerpeter (2014-12-10 16:14:33+00:00)
Title: An ability to resolve references using ASM, without classloading

ClassNodeResolver now has two optimization options, both true by default: asmResolving to enable resolving with ASM (see AsmDecompiler class), and classLoaderResolving to enable the old, classloader-based resolution. Command-line compilers are supposed to turn the latter off.

I haven't observed significant difference in running times for tests or building groovy-core, but compiling against this jar in IntelliJ definitely gives some speedup. I'm not even sure that ASM resolving should be on by default, but as I haven't observed slowdowns on my Linux, I turned it on. Testing on other OSes might be helpful.

A couple unresolved questions:
* Java5 treatment of ParameterizedType is incorrect: it doesn't take into account getOwnerType(). I've made ASM decompiler behave the same way for now. I don't know how to represent such types in ClassNode API.
* Java5#configureClassNode has some logic concerning package annotations. I strongly suspect that it never works because compiled classes don't have modules (and hence packages). I couldn't find how to make this code work, so I didn't reflect the same logic in ASM decompiler.

Possible improvements:
* Lazy MethodNode parameters and return type parsing
* Caching ClassStub. One should be careful to avoid false positives when different same-named classes are used.

BTW: how about creating a class/interface with all available optimization options as constants?