[
https://issues.apache.org/jira/browse/GROOVY-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18141698#comment-18141698
]
ASF GitHub Bot commented on GROOVY-12568:
-----------------------------------------
codeconsole opened a new pull request, #3287:
URL: https://github.com/apache/groovy/pull/3287
https://issues.apache.org/jira/browse/GROOVY-12568
17ad5e4473 removed the only line that reads the
`groovy.runtime.package.check` system property into the optimization options.
The Javadoc of `CompilerConfiguration.RUNTIME_PACKAGE_CHECK` and the
COMPATIBILITY entry added in the same commit still tell users to set it, but on
master it no longer has any effect.
`StaticCompileRuntimePackageTest.testSystemProperty` has failed on master
since then (for example
https://github.com/apache/groovy/actions/runs/42730490227, on every JDK), and
so on every pull request built against master. This puts the line back, and the
test passes again.
The GROOVY_6_0_X port (873360d917) still reads the property, so only master
needs this.
> SC: protected and package-private members of a class defined by another
> GroovyClassLoader compilation fail with IllegalAccessError
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12568
> URL: https://issues.apache.org/jira/browse/GROOVY-12568
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
> Affects Versions: 6.0.0
> Reporter: Scott Murphy Heiberg
> Assignee: Paul King
> Priority: Major
> Fix For: 7.0.0-alpha-1
>
>
> The JVM allows access to a protected or package-private member only within
> the same run-time package, which is the package name and the class loader. A
> {{GroovyClassLoader}} defines each compilation in memory with a class loader
> of its own: a {{GroovyShell}} script, {{parseClass}}, a script run with
> {{groovy}}, JSR-223. So a class of an earlier parse, or a precompiled class
> used by such a script, is in another run-time package even with the same
> package name. Statically compiled code calls such members directly and fails;
> dynamic code goes through the meta-class and works.
> {code:groovy}
> def shell = new GroovyShell()
> shell.evaluate '''package p
> class A {
> @groovy.transform.PackageScope A(String s) { }
> @groovy.transform.PackageScope String name() { 'a' }
> @groovy.transform.PackageScope String tag = 't'
> }
> true
> '''
> shell.evaluate '''package p
> @groovy.transform.CompileStatic
> List make() { def a = new A('x'); [a.name(), a.tag] }
> make()
> ''' // IllegalAccessError; without @CompileStatic: ['a', 't']
> {code}
> The same happens for map-style construction, instance and static methods,
> getters and setters used as properties, method references such as
> {{a::name}}, and field reads and writes including {{.@}}, {{+=}} and {{++}}.
> Expected: with the option {{CompilerConfiguration.RUNTIME_PACKAGE_CHECK}},
> which {{GroovyShell}} turns on for the class loader it creates, such an
> access is reported when the class is generated. With it off, the bytecode and
> the {{IllegalAccessError}} stay as they are. Code compiled to class files is
> not affected. Statically compiled code does not go through the meta-class for
> these members: compile time and run time may see different classes, and the
> meta-class can influence the call.
> Split out: GROOVY-12717 (protected members of another package), GROOVY-12718
> (dynamic {{super.f}}, {{super.@f}} and {{this.@f}} of such a field),
> GROOVY-12719 (the invokedynamic {{GroovyBugError}} for a constructor the JVM
> refuses). {{super.m()}} of such a method is GROOVY-12570.
> PR: https://github.com/apache/groovy/pull/3097
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
