On 10/07/2017 10:44, Jochen Theodorou wrote:
:
Example:
module A:
class Foo {
protected void foo(){}
}
Groovy program:
class X extends Foo {
def bar() {return {foo()}}
}
if Foo is in an exported package, then it is legal for X to call foo,
even though it is protected. But bar() does not directly call foo, it
will do so in a Closure (not functional closure, not lambdas).
and therein is the issue because protected members should only be
accessible in the sub-class (or same package).
In a Closure the implicit this has no fixed meaning and is realized as
anonymous inner class. With our current protocol the call to foo ends
up in the meta class logic, which then executes the method call. This
will then cause a warning "WARNING: An illegal reflective access
operation has occurred".
Do you have any control on the code that is generated for X?
-Alan
