[
https://issues.apache.org/jira/browse/GROOVY-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18135965#comment-18135965
]
ASF GitHub Bot commented on GROOVY-12568:
-----------------------------------------
codeconsole commented on PR #3097:
URL: https://github.com/apache/groovy/pull/3097#issuecomment-6552330681
@blackdrag Agreed: the meta-class route goes. I'd take path 2.
- **Path 1**: the code compiles and fails with `IllegalAccessError` on first
use. A `@CompileStatic` script in a `GroovyShell` that calls a package-private
method of a class from an earlier parse, or of a library class in the same
package, is enough.
- **Path 3** needs path 2's check first, plus a bootstrap method in the
runtime that generated code depends on, plus changes at every access site. It
can be its own issue later if someone needs such code to run.
- **Path 2** is exact. Each in-memory compilation is defined by a new
`InnerLoader`, which defines only that compilation's classes. A class with the
same package name that is not part of the compilation is therefore in another
run-time package, whatever class the name resolves to at run time.
`isInSameRuntimePackage` and the marker from #3022 compute that. The exception
is a `GroovyClassLoader` subclass whose collector defines all compilations with
one loader, which is one more reason for the option.
Rework:
- **#3097**:
- option `CompilerConfiguration.RUNTIME_PACKAGE_CHECK`, off by default, in
the optimization options like `ERROR_RECOVERY`. It has no effect on code
compiled to class files;
- `GroovyShell` turns it on for the loader it creates, unless the
configuration sets it (`CompilerConfiguration.DEFAULT` is read-only);
- with it on, a protected or package-private constructor, method or field
of another run-time package, outside the protected subclass rule, is reported
when the class is generated. That is where the access is emitted, so only
`@CompileStatic` code is affected; `@TypeChecked` code calls through the
meta-class and works. The message says the class was defined by another class
loader and suggests `@CompileDynamic`;
- with it off, the bytecode is the same as on master;
- the writer changes that go through the meta-class are dropped,
`invokeNew` included.
- **#3098** becomes the same check for a package-private class, under the
same option.
- **Protected members of another package** (`new A(...)` of a protected
constructor in a subclass, a protected method through a superclass receiver)
are Java's rules, unrelated to loaders. They move to their own issue,
unconditional like #3019: such code fails verification today. The meta-class
route for `a.@f = v` is dropped.
- **Dynamic code**, each its own issue:
- no `super$` method for a package-private method of another run-time
package moves into #3099;
- dynamic `super.f`, `super.@f` and `this.@f` of such a field, leaving
static compilation unchanged;
- the invokedynamic `GroovyBugError` for a constructor the JVM refuses.
Does that split and name work for you?
> 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
> Priority: Major
>
> 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 {{++}}.
> In dynamic code, {{super.f}}, {{super.@f}} and {{this.@f}} of such a field,
> and {{super.m()}} of such a method, fail the same way, because the {{super$}}
> helper and the field instructions are generated directly.
> Related, in a subclass in another package, under static compilation:
> * {{new A(...)}} of a protected constructor of another package compiles and
> then fails verification. As in Java, only {{super(...)}} and {{new A(...)
> {}}} can call it.
> * a protected method of another package called through a receiver of the
> superclass type ({{a.m()}}, {{a.name}}, {{a::m}}, {{A::m}}) compiles and then
> fails with {{VerifyError}}: the GROOVY-7325 check compared the types the
> wrong way round. {{a.@field = value}} through such a receiver fails
> verification too.
> * with invokedynamic, a dynamic {{new ObjectInputStream()}} in a subclass
> fails with {{GroovyBugError}} ("member is protected") instead of "could not
> access constructor".
> Expected: such members are reached through the meta-class, as in dynamic
> code; code compiled to class files (groovyc, Gradle, Maven, joint
> compilation) keeps direct access, as javac does; the two verification
> failures are compile errors.
> PR: https://github.com/apache/groovy/pull/3097
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
