[
https://issues.apache.org/jira/browse/GROOVY-12718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18140040#comment-18140040
]
ASF GitHub Bot commented on GROOVY-12718:
-----------------------------------------
codeconsole opened a new pull request, #3252:
URL: https://github.com/apache/groovy/pull/3252
In dynamic and `@TypeChecked` code, a package-private field of a superclass
with the same package name but of another class loader, such as a class of an
earlier parse of the same `GroovyShell`, is reached through the meta-class by
`f` and `this.f`. The forms that go directly to the field fail:
```groovy
// first parse
package p
class F { @PackageScope String pf = 'pf' }
// second parse with the same GroovyShell
package p
class C extends F {
def test() {
super.pf // IllegalAccessError, as are super.@pf and
this.@pf
this.@pf = 'w' // and writes through them
}
}
```
4.0.32, 5.0.8 and 6.0.0 fail the same way.
`AsmClassGenerator.visitPropertyExpression` and `visitAttributeExpression`
decide by the package name and write `GETFIELD` or `PUTFIELD`. They now leave
such a field to the meta-class in dynamic code, using `isInSameRuntimePackage`,
which only knows the case for an in-memory compilation of a `GroovyClassLoader`.
Static compilation is unchanged: it does not select a member at run time.
#3097 (GROOVY-12568) reports such an access there. A protected field, which a
subclass can use directly, and a field of the same compilation are still
accessed directly.
This and #3097 add an import next to each other in `AsmClassGenerator`;
whichever lands second keeps both.
## Compatibility
Code that failed with `IllegalAccessError` now works.
## Tests
`DynamicFieldOfAnotherRuntimePackageTest`:
`testReadOfPackagePrivateFieldOfSuperclass` and
`testWriteOfPackagePrivateFieldOfSuperclass`, each dynamic and `@TypeChecked`,
fail without the change. The other tests pin what must not change: closures, a
protected field and a field of the same compilation stay as they are, and
static compilation still fails at run time without #3097. The
`org.codehaus.groovy.classgen.asm.sc`, `groovy.transform.stc` and `gls` tests
pass, apart from the two `testSelfReferentialTypeParameter5` tests, whose
`@Grab` of netty did not resolve on my network. The Checkstyle and CodeNarc
gates pass.
> super.f, super.@f and this.@f of a package-private field of a superclass of
> another class loader fail with IllegalAccessError in dynamic code
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12718
> URL: https://issues.apache.org/jira/browse/GROOVY-12718
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.32, 5.0.8, 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {code:groovy}
> def shell = new GroovyShell()
> shell.evaluate '''package p
> class F { @groovy.transform.PackageScope String pf = 'pf' }
> true'''
> shell.evaluate '''package p
> class C extends F {
> def test() {
> assert pf == 'pf' // works
> assert this.pf == 'pf' // works
> super.pf // IllegalAccessError, as are super.@pf,
> this.@pf and writes through them
> }
> }
> new C().test()'''
> {code}
> *Actual:* {{IllegalAccessError: class p.C tried to access field p.F.pf}}.
> *Expected:* the value of the field, through the meta-class, as for {{pf}} and
> {{this.pf}}.
> Cause: {{F}} comes from an earlier parse, so it has the same package name as
> {{C}} but another class loader, which makes it another run-time package.
> {{AsmClassGenerator.visitPropertyExpression}} and
> {{visitAttributeExpression}} decide by the package name and write
> {{GETFIELD}} or {{PUTFIELD}}, in dynamic and {{@TypeChecked}} code too.
> Verified on 4.0.32, 5.0.8, 6.0.0 and master.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
