[ https://issues.apache.org/jira/browse/GROOVY-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516716#comment-16516716 ]
Alexander Veit commented on GROOVY-8649: ---------------------------------------- Thank you John, your suggested workaround seems to work. However, I doubt that it is a good idea to turn on {{asmResolving}} by default. Classes in a JVM are supposed to be loaded by a class loader in a reasonable hierarchy. If Groovy deviates from this rule it will probably break all sorts of things like object equality, {{instanceof}} checks, security mechanisms etc.. Especially in Java applications that use Groovy as an embedded language. > Class loading in Groovy 2.5 breaks class loading hierarchy > ---------------------------------------------------------- > > Key: GROOVY-8649 > URL: https://issues.apache.org/jira/browse/GROOVY-8649 > Project: Groovy > Issue Type: Bug > Components: class generator > Affects Versions: 2.5.0 > Reporter: Alexander Veit > Priority: Blocker > > Prior to Groovy 2.5 GroovyClassLoader passed classes requested by script code > like > {quote}def obj = new org.example.NonScriptableClass(){quote} > to its parent class loader (hereby the NonScriptableClasses are Java classes). > We use this behavior to allow or deny loading of Java classes with the parent > class loader based on certain annotations on the respective class. > With Groovy 2.5 this behavior has changed. org.example.NonScriptableClass is > no more passed to the parent class loader. This breaks our security mechanism. -- This message was sent by Atlassian JIRA (v7.6.3#76005)