[
https://issues.apache.org/jira/browse/GROOVY-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18141738#comment-18141738
]
ASF GitHub Bot commented on GROOVY-12568:
-----------------------------------------
daniellansun opened a new pull request, #3288:
URL: https://github.com/apache/groovy/pull/3288
The no-arg `CompilerConfiguration` constructor already reads the other
optimization-option system properties (`groovy.target.indy`,
`groovy.attach.groovydoc`, and so on), but it stopped reading
`groovy.runtime.package.check`. A new configuration therefore left
`runtimePackageCheck` unset, which is what made
`StaticCompileRuntimePackageTest.testSystemProperty` fail on current master
(for example [this LTS
job](https://github.com/apache/groovy/actions/runs/42734553125/job/129568245863)).
This restores that read. An unset property still leaves the option unset, so
`GroovyShell` continues to enable the check for the class loader it creates
unless the property or option is set to `false`.
> 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)
