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?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
