[
https://issues.apache.org/jira/browse/GROOVY-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17414229#comment-17414229
]
Eric Milles commented on GROOVY-10231:
--------------------------------------
See also GROOVY-4156
> 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
> Priority: Major
>
> 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)
