Svatopluk Dedic created GROOVY-10231:
----------------------------------------
Summary: Groovy compiler loads user project class into JVM
Key: GROOVY-10231
URL: https://issues.apache.org/jira/browse/GROOVY-10231
Project: Groovy
Issue Type: Bug
Components: Compiler
Affects Versions: 3.0.8
Reporter: Svatopluk Dedic
Groovy compiler uses *ClassNode*.*getTypeClass* which may load even user
project's code to the compiling JVM. I understand this is not an issue for a
standard Groovy usage scenario, when a *.groovy* source is executed; since
compler & the execution runtime runs in the same process, so the annotation
would be eventually loaded anyway.
The issue becomes more apparent with *@CompileStatic* instruction that produces
an executable .class file, or as a part of Groovy build (see e.g. Spock
Framework) where the compiler JVM runs potentially in a different environment -
and maybe even in CI environment. The annotation class itself is relatively
harmless; but the annotation may reference other user types (method return
types), which are regular classes / enums that may contain executable code in
their static initializers (for example). I admit I didn't manage to fool Groovy
compiler into executing user code yet ;) but it's a matter of calling methods
like getSuperclass(), getAnnotations() or getMethods() on annotation method's
return type Class.
One of the prominent usages is *ResolveVisitor.visitAnnotations()* that uses
*ClassNode.getTypeClass()* so it can inspect (user) annotations of a compiled
class.
In case of NETBEANS-5982, the code analysis that runs Groovy Compiler
(partially) runs in an IDE. While we can use 'sandbox' ClassLoader that will
load the user class and will be trashed so next time the user class can be
loaded from a fresh (possibly recompiled) version, it's still IMHO unfortunate
to pollute analyzing JVM with user types - most notably if Groovy can already
decompile classes into ClassNodes and most of the checks that are now done
(e.g. Class.isAssignableFrom) are doable using ClassNode methods & related
utilities - avoiding class loading.
But there are more usages of .getTypeClass()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
