GROOVY-12568: SC: reach protected and package-private members of a class of another GroovyClassLoader compilation through the meta-class by codeconsole · Pull Request #3097 · apache/groovy

codeconsole · 2026-10-30T00:04:36Z

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 from 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 accessed such members directly and failed with IllegalAccessError:

// first parse
package p
class A { @PackageScope A(String s) {}; @PackageScope String name() { 'a' }; @PackageScope String tag = 't' }

// second parse with the same GroovyShell
package p
@CompileStatic List make() { def a = new A('x'); [a.name(), a.tag] }

For a compilation defined in memory, statically compiled code now reaches such a constructor, method or field through the meta-class, as dynamic code does. This covers new and map-style construction, instance and static methods, getters and setters used as properties, method references such as a::name (through a synthetic method), 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 work too (no super$ method is generated for a package-private method of another run-time package). Public members, classes of the same compilation, and protected members used from a subclass through this, super or a receiver of the subclass type are still accessed directly. Code compiled to class files (groovyc, Gradle, Maven, Ant, joint compilation with Java) keeps direct access to the members of the other classes of its package, as javac does, and a full and an incremental build give the same bytecode. The rule is AsmClassGenerator.isInSameRuntimePackage, which #3022 introduces for constructor references; this applies it to the rest.

Protected members of another package, in a subclass, under static compilation:

new A(...) of a protected constructor of another package is reported: "Cannot call protected constructor for p.A from class q.B". As in Java, only super(...) and new A(...) {} can call it. It used to compile and then fail verification. The error is raised while the class is generated, so @TypeChecked code is not checked for it and works through the meta-class.
A protected method of another package called through a receiver of the superclass type (a.m(), a.name, a::m, A::m) is reported as "Cannot access method", as GROOVY-7325 intended: its check compared the types the wrong way round. These used to compile and then fail with VerifyError. a.@field = value through such a receiver now goes through the meta-class, like the read.

With invokedynamic, a dynamic new of a constructor that the JVM refuses, such as new ObjectInputStream() in a subclass, now fails with "could not access constructor", as it does without invokedynamic, instead of GroovyBugError.

COMPATIBILITY.md has an entry for the meta-class semantics of these accesses and the two new compile errors.

This builds on #3022 (constructor references), which adds isInSameRuntimePackage, the GroovyClassLoader marker and StaticInvocationWriter.isDirectlyAccessible; its commits are included here until it is merged.

Tests

All marked // GROOVY-12568, each failing without the change it covers:

StaticCompileRuntimePackageTest: constructors, map-style construction (literal and Map variable), methods, properties, method references (also in static and default methods of an interface) and fields of a class of another class loader, with and without invokedynamic, compared with the same code compiled dynamically; bytecode tests pin that classes of the same compilation, public members, class files, incremental builds and joint compilation keep direct access;
bugs.Groovy12568: dynamic super.m() of a package-private method of another class loader, and invokedynamic new of a protected constructor of another package or of the JDK;
ConstructorsSTCTest and StaticCompileConstructorsTest: new of a protected constructor of another package, with super(...) and anonymous classes still direct;
Groovy7325Bug: protected methods of another package through a receiver of the superclass and of the subclass.

The groovy.*, gls.*, bugs.*, org.codehaus.groovy.classgen and org.codehaus.groovy.transform packages pass (13,458 tests), apart from bugs.Groovy12363, which also fails on master when it runs after bugs.Groovy12142 in the same JVM (GROOVY-12580, #3096, fixes it), and bugs.Groovy9815, whose @Grab download failed once and passes when rerun. The Checkstyle and CodeNarc gates pass.

…h new directly only within the compilation unit Under static compilation, new A(...) of a protected or package-private constructor of a class with the same package name was compiled to NEW and INVOKESPECIAL. The JVM allows that call only within the same run-time package, which is the package name and the class loader, so it failed with IllegalAccessError when A came from another class loader: a class of an earlier parse of the same GroovyShell, which GroovyClassLoader defines with another InnerLoader, or a precompiled class used by a script. Dynamic and type-checked code create such an object through the meta-class and work. Such a constructor is now called directly only when its class is compiled in the same compilation unit, which defines all its classes with one class loader, as for a constructor reference. Otherwise the object is created through the meta-class, which selects the constructor at run time. This also applies to the no-argument constructor that a map-style construction such as new A(name: 'x') calls before it sets the properties. Public constructors, and constructors of classes of the same compilation unit, are still called directly. The constructor reference writer uses the same check.

… only within the compilation unit Under static compilation, a call to a protected or package-private method of a class with the same package name was compiled to a direct INVOKEVIRTUAL, INVOKESTATIC or INVOKESPECIAL. As for a constructor, the JVM allows that call only within the same run-time package, so it failed with IllegalAccessError when the class came from another class loader, for example a class of an earlier parse of the same GroovyShell. This also hit a protected or package-private getter or setter used as a property, such as a.name or a.name = value. Such a method is now called directly only when its class is compiled in the same compilation unit, or when the JVM allows the call from any package: a protected method called from a subclass on this, super or a receiver of the subclass type, or a protected static method called from a subclass. Otherwise the method is selected at run time through the meta-class, as dynamic code does. Public methods, and methods of classes of the same compilation unit, are still called directly.

…nother compilation unit through a synthetic method A statically compiled method reference such as m::pm, M::pm or M::spm gives LambdaMetafactory a method handle for the method. For a protected or package-private method of a class with the same package name, the JVM resolves that handle only within the same run-time package, so the reference failed with IllegalAccessError when the class came from another class loader, for example a class of an earlier parse of the same GroovyShell. For such a method of a class of another compilation unit, the reference now targets a synthetic static method of the current class that calls the method. The invocation writer compiles that call directly when the JVM allows it from any package (a protected method called through the subclass), or else selects the method at run time. Method references to methods of classes of the same compilation unit, and to public methods, still use a method handle for the method itself.

…ly within the compilation unit AsmClassGenerator.isFieldDirectlyAccessible decided by the package name if a protected or package-private field can be read or written with GETFIELD, PUTFIELD, GETSTATIC or PUTSTATIC. As for methods and constructors, the JVM allows that only within the same run-time package, so the access failed with IllegalAccessError when the class came from another class loader, for example a class of an earlier parse of the same GroovyShell. Under static compilation this hit a.field, a.@field, Type.field, an implicit field of a superclass, compound assignments and increments. Dynamic code hit it for super.field, super.@field and this.@field of a superclass. A protected field of a superclass with the same package name but of another compilation unit was also read through a receiver of the superclass type, which fails verification ("Bad access to protected data in getfield") when the classes are in different run-time packages. Such a field is now accessed directly only when its class is compiled in the same compilation unit, or through the subclass rule for a protected field (with a receiver of the current class). Otherwise it is read and written through the meta-class, as dynamic code does. Public fields, and fields of classes of the same compilation unit, are still accessed directly.

…ckage instead of failing verification Outside its package, a protected constructor can only be called by super(...) or by creating an anonymous inner class (JLS 6.6.2.2). The type checker accepts new A(...) of such a constructor in a subclass of A, as it accepts other protected members there, and type-checked code creates the object through the meta-class. Under static compilation, the call was compiled to NEW and INVOKESPECIAL, and the class failed verification when it was loaded: "VerifyError: Bad access to protected <init> method". The same happened for a map-style construction such as new A([:]), which calls the protected no-argument constructor. The static compiler now reports "Cannot call protected constructor for A from class B", as it reports a protected method called on a receiver that is not the subclass (GROOVY-7325). super(...), this(...) and new A(...) {} still call the constructor directly. A constructor reference A::new to such a constructor still selects it at run time.

… through a superclass receiver Outside its package, a protected instance method or field can be used only through a receiver of the subclass (JLS 6.6.2.1, JVMS 4.10.1.8). For a method, the static compiler meant to report such a call (GROOVY-7325), but its check compared the types the wrong way round: it tested whether the current class is a subtype of the receiver type instead of the reverse. So a.m() with a receiver of the superclass type, in a subclass in another package, was compiled to a direct call and the class failed verification: "VerifyError: Bad access to protected data in invokevirtual". This also hit a protected getter or setter used as a property (a.name, a.name = value). A method reference such as a::m or A::m to such a method failed with BootstrapMethodError, and an attribute assignment a.@field = value failed verification in putfield. The check now requires the receiver to be of the current class (or this, super or a static method), so such a call or method reference is reported as "Cannot access method", as GROOVY-7325 intended and as javac does. An attribute assignment through such a receiver is now made through the meta-class, as the attribute read a.@field already was. Calls through this, super or a receiver of the subclass type are still direct.

…amic cannot access the constructor A dynamic new of a protected constructor of another package, in a subclass, is accepted by Groovy and by the type checker. With invokedynamic, the constructor selector unreflected the selected constructor with the lookup of the calling class and turned an IllegalAccessException into GroovyBugError. For a constructor that the JVM refuses to the caller, such as the protected ObjectInputStream() of the encapsulated java.io package called by new in a subclass, the call failed with "BUG! UNCAUGHT EXCEPTION: member is protected". As the property selectors do since GROOVY-12314, the constructor selector now treats the refusal as an access-control outcome and leaves the call to the meta-class, which reports "could not access constructor", as the call does without invokedynamic. A constructor that reflection can reach, such as a protected constructor of a class of another package in the unnamed module, is still called.

…ethod of another run-time package For a dynamic super.m() call, the class gets a synthetic super$N$m method that calls the superclass method with INVOKESPECIAL. For a package-private method of a superclass with the same package name but of another compilation unit, the classes may be in different run-time packages, for example when the superclass comes from an earlier parse of the same GroovyShell, and the JVM refuses the call: super.m() failed with IllegalAccessError. Such a method, and a package-private method of a superclass of another package, no longer gets a super$ method, and the meta-class calls the superclass method reflectively, as it does for a statically compiled super.m() of such a method.

…ugh the meta-class only for classes defined in memory The previous commits accessed a protected or package-private member of a class with the same package name through the meta-class whenever that class was compiled by another compilation unit. That also hit class files: a Java class of a joint compilation, a main class used by a test, a class left over from an incremental compilation. Such classes are loaded by one class loader at run time, as javac assumes, so the direct access worked; the meta-class path was slower, followed meta-class semantics, needed reflection metadata in a native image, and made an incremental build give other bytecode than a full one. The run-time package of such a class only differs when the classes are defined in memory by a GroovyClassLoader, which defines each compilation (a GroovyShell script, parseClass, JSR-223) with an InnerLoader of its own. GroovyClassLoader now records that on the compilation unit, and AsmClassGenerator.isInSameRuntimePackage treats a class of another compilation unit as another run-time package only then. Constructors, map-style construction, methods, getters and setters, method references, fields, dynamic super and this.@ access and super$ methods all use this check. Compiling to class files keeps direct access, as before these changes and as javac does. (The rest of the change: new, map-style construction, methods, getters and setters, method references to methods, fields, dynamic super and this.@ access and super$ methods. The GroovyClassLoader marker, isInSameRuntimePackage and constructor references come first.)

The tests for protected and package-private members of a class of another compilation now compile it through a GroovyClassLoader, which defines it with another class loader; classes compiled to class files keep direct access. Name the tests accordingly.

…rules of constructor references - isInSameRuntimePackage: isPrimaryClassNode() stands for "defined by the class loader of the accessing class", not for "compiled from source". - StaticInvocationWriter.isDirectlyAccessible: unlike isMemberDirectlyAccessible it has no subclass rule, since the verifier rejects NEW and INVOKESPECIAL of a protected constructor of another package in a subclass too. - findConstructorReferenceTarget: a selected constructor is called directly, so a meta-class constructor override is not used, as for a statically compiled new. The guard comment now says why enums are left to the meta-class: the type checker accepts an enum constructor reference whose arguments match the generated constructor, but Java code cannot instantiate an enum. - addSyntheticMethod: the ACC_FINAL rule of JVMS 4.6 applies to every helper method of a method reference in an interface. (The part on statically compiled new; the rest comes with constructor references.)

… interface All helper methods that a method reference adds to the current class are created by addSyntheticMethod, which leaves out ACC_FINAL in an interface. The interface tests covered the constructor-reference and variadic helpers; they now also cover the array constructor reference, the static extension method helper (Thread::startDaemon), the Class method helper (String::getName) and the helper that calls a package-private method of a class of another class loader (M::spm, M::pm), in static and default methods, and check that every helper is private and not final. With ACC_FINAL put back, both tests fail with ClassFormatError (illegal modifiers 0x101A). (The case of a method of another run-time package; the other helper methods are tested with constructor references.)

…AbstractBytecodeTestCase MethodReferenceTest and StaticCompileRuntimePackageTest each had a copy of the helper that compiles a script against the classes of an earlier parse of the same GroovyClassLoader, and of the code that keeps only the instructions of one method. AbstractBytecodeTestCase now provides them as compileAgainstLibrary, extractMethodSequence and selectMethod, and both tests use them. Test code only; the tests are unchanged. (Here StaticCompileRuntimePackageTest; MethodReferenceTest was moved to the helpers with constructor references.)

…errors COMPATIBILITY.md describes how statically compiled code of a compilation that a GroovyClassLoader defines in memory reaches protected and package-private members of classes of other compilations, and the new compile errors for new of a protected constructor of another package and for a protected method of another package called through a superclass receiver. StaticInvocationWriter notes that the constructor error is reported during class generation, so @TypeChecked code is not checked for it and works dynamically.

…ass of another class loader Since GROOVY-12454, new A(map) with a Map variable, under static compilation, calls the no-argument constructor and then sets the properties of the map at run time. For a class of an earlier parse of the same GroovyShell whose no-argument constructor is package-private, the constructor is called through the meta-class, as for a map literal.

codecov-commenter · 2026-10-30T00:57:29Z

Codecov Report

❌ Patch coverage is 82.52427% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.1660%. Comparing base (0cc667e) to head (bead3ad).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
...sc/StaticTypesMethodReferenceExpressionWriter.java	86.8421%	0 Missing and 5 partials ⚠️
...groovy/classgen/asm/sc/StaticInvocationWriter.java	80.9524%	0 Missing and 4 partials ⚠️
...ovy/classgen/asm/sc/StaticTypesCallSiteWriter.java	75.0000%	0 Missing and 4 partials ⚠️
...rm/sc/transformers/ConstructorCallTransformer.java	83.3333%	0 Missing and 3 partials ⚠️
...rg/codehaus/groovy/classgen/AsmClassGenerator.java	85.7143%	0 Missing and 1 partial ⚠️
...java/org/codehaus/groovy/vmplugin/v8/Selector.java	50.0000%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@                Coverage Diff                 @@
##               master      #3097        +/-   ##
==================================================
+ Coverage     74.1374%   74.1660%   +0.0286%     
- Complexity      43718      43778        +60     
==================================================
  Files            1692       1692                
  Lines          149513     149601        +88     
  Branches        28359      28395        +36     
==================================================
+ Hits           110845     110953       +108     
+ Misses          28458      28427        -31     
- Partials        10210      10221        +11

Files with missing lines	Coverage Δ
...va/org/codehaus/groovy/classgen/asm/MopWriter.java	`86.0760% <100.0000%> (+0.1785%)`	⬆️
...rg/codehaus/groovy/classgen/AsmClassGenerator.java	`85.9375% <85.7143%> (+0.0501%)`	⬆️
...java/org/codehaus/groovy/vmplugin/v8/Selector.java	`81.4262% <50.0000%> (+0.1970%)`	⬆️
...rm/sc/transformers/ConstructorCallTransformer.java	`94.0298% <83.3333%> (-1.1702%)`	⬇️
...groovy/classgen/asm/sc/StaticInvocationWriter.java	`77.8793% <80.9524%> (+0.4600%)`	⬆️
...ovy/classgen/asm/sc/StaticTypesCallSiteWriter.java	`80.4436% <75.0000%> (+2.4810%)`	⬆️
...sc/StaticTypesMethodReferenceExpressionWriter.java	`89.3082% <86.8421%> (-0.0100%)`	⬇️

... and 13 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

daniellansun

LGTM for GROOVY-12568 (and the bundled GROOVY-12488 constructor-reference work this branch carries).

JVM run-time package = package name + ClassLoader. Marking each GroovyClassLoader in-memory compilation (InnerLoader metadata on the CompileUnit) and then refusing direct bytecode access to protected / package-private members across that boundary — falling back to meta-class / synthetic helpers, and emitting the new compile errors for illegal new of a protected ctor / protected method via a foreign receiver — matches JLS/JVMS and dynamic Groovy.

AsmClassGenerator.isInSameRuntimePackage / isFieldDirectlyAccessible, StaticInvocationWriter.isDirectlyAccessible + writeDynamicConstructorCall, MopWriter skipping impossible super$ bridges, and the indy ctor path are coherent. StaticCompileRuntimePackageTest + Groovy12568 cover GCL isolation, map-style construction, method/ctor refs, and fields. COMPATIBILITY.md / operator docs spell the Groovy 7 behavior change clearly.

CI fully green. Codecov ~84% patch with mostly branch partials (no large missing blocks) — acceptable for this surface.

Merge notes: branch is ~30 commits ahead / a few behind master; open #3022 (GROOVY-12488) overlaps — prefer one landing path. #3098 / #3099 are siblings on top of this tip; merge this first.

daniellansun · 2026-10-30T15:00:22Z

Friendly ping: this PR is approved. If there are no objections within 72 hours, this PR will be merged. Thanks!

codeconsole · 2026-10-30T15:28:28Z

@daniellansun Thanks. #3097 is stacked on #3022 (GROOVY-12488), so merging it also lands #3022's commits. Either order works: merge #3022 first and #3097 then shows only its own commits, or merge #3097 and close #3022. #3098 and #3099 go after #3097. I merged master into all four to clear a COMPATIBILITY.md conflict (both sides added an entry; kept both).

# Conflicts: # src/main/java/org/codehaus/groovy/classgen/asm/sc/StaticTypesMethodReferenceExpressionWriter.java

…to the language rule For a public or private field the language rule of isMemberDirectlyAccessible decides. For a protected or package-private field, JVMS 5.4.4 allows access from the run-time package of the declaring class, or to a protected field from a subclass. That condition implies isMemberDirectlyAccessible, so it replaces it there instead of being checked after it.

codeconsole · 2026-10-31T01:07:07Z

@blackdrag Simplified in e9c86b5:

if (field.isPublic() || field.isPrivate()) { // nestmates can access a private field
    return isMemberDirectlyAccessible(field.getModifiers(), declaringClass, accessingClass);
}
// JVMS 5.4.4
return isInSameRuntimePackage(declaringClass, accessingClass)
    || (field.isProtected() && accessingClass.isDerivedFrom(declaringClass));

Public and private fields: the language rule decides; the run-time package does not matter for them, and a private field is reachable only from nestmates, which are compiled together.
Protected and package-private fields: JVMS 5.4.4 allows access from the run-time package of the declaring class (package name plus defining loader), and to a protected field from a subclass. isMemberDirectlyAccessible also accepts any class with the same package name, which is the excluded case: a class compiled earlier by another GroovyClassLoader compilation has the same package name but another loader, and GETFIELD of its field fails with IllegalAccessError. For these fields the JVM condition implies isMemberDirectlyAccessible (same run-time package implies same package name), so it replaces that call instead of being checked after it. Same shape as StaticInvocationWriter.isDirectlyAccessible(ConstructorNode).
Both parts are needed: checking the package name instead of isInSameRuntimePackage fails the 5 field tests of StaticCompileRuntimePackageTest; dropping the subclass part fails FieldsAndPropertiesStaticCompileTest.testReadFieldFromSuperClass2/3, MethodReferenceTest.testInnerClassProtectedMethodReference and StaticCompileRuntimePackageTest.testProtectedFieldOfSuperclassOfAnotherClassLoaderIsAccessedDirectly.

The result is the same as before for every field, so no test changed. Also merged master now that #3022 has landed, so this PR shows only GROOVY-12568. MethodReferenceTest.testMethodReferencesInStaticAndDefaultMethodsOfInterface fails on master itself since #3056; #3116 fixes it.

blackdrag · 2026-10-31T21:19:39Z

Now that #3019 is merged I think the idea of this PR is actually in conflict.

codeconsole · 2026-10-31T21:29:02Z

@blackdrag I see the conflict. For the same failure, IllegalAccessError at run time, #3019 reports a compile error and this PR quietly goes dynamic.

What this PR does now:

Already in line with GROOVY-12484: STC: method and constructor calls on an inaccessible ty… #3019. These cases are rejected at compile time, as Java rejects them: new A(...) of a protected constructor of another package, and a protected method of another package called through a superclass receiver.
The part that conflicts. A protected or package-private member of a class that has the same package name but was defined by another GroovyClassLoader compilation (a class from an earlier GroovyShell parse, for example). JLS 6.6 counts it as accessible, so GROOVY-12484: STC: method and constructor calls on an inaccessible ty… #3019's hasAccessToClass accepts it. The JVM refuses it, so this PR routes the access through the meta-class. GROOVY-12569: SC: do not name a package-private class of another GroovyClassLoader compilation in bytecode #3098 does the same for a package-private class from another loader, and GROOVY-12570: let super.m() reach a package-private method of a superclass of another class loader #3099 for super.m().

The alternative in line with #3019: the type checker treats such a member or class as inaccessible and reports "Cannot access ...". This applies to @CompileStatic and @TypeChecked, while dynamic code keeps working. The compiler knows the case for certain, because the class comes from a loader other than the in-memory compilation's. Code compiled to class files is unaffected, as now. Either way it is no regression: today such code compiles and then fails with IllegalAccessError. The writer changes that route accesses through the meta-class (constructors, methods, method-reference helpers, fields) would be dropped, which makes the PR much smaller.

If that is what you mean, I'll rework #3097 this way, and #3098 and #3099 with it. I also merged master in (93d5776); Groovy12484 and this PR's tests pass together.

blackdrag · 2026-10-31T23:22:00Z

@codeconsole I think the dynamic path does not make sense here for static compilation because:

compile time and runtime may see different classes
meta class can influence constructor invocation
runtime may still fail

I see a few paths forward here:

do nothing and close the issue as won´t fix
check at compile time and fail.
check at compile time and implement a reflective path, for example via its own invokedynamic

For (2) I would use the compiler configuration to set if want to check this, since this is a very specific scenario and GroovyShell could then for example set it by default. Unchecked means path (1)
For (3) I would also use a compiler configuration option to control if we want to do this. (2) could be a fallback, I would still make (1) the default.

path 3 makes this of course a much bigger implementation since we do not have that so far. Well maybe the LambdaFactory utilities can help here, since we really actually want a constant call site for this. And path (1) is pretty much a "won´t fix"

I would not use ScriptByteCodeAdapter#invokeNew for this. What variant makes most sense for you?

codeconsole · 2026-11-01T02:27:36Z

@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 GROOVY-12488: SC: call the constructor of a constructor reference directly #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:

GROOVY-12568: SC: reach protected and package-private members of a class of another GroovyClassLoader compilation through the meta-class #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.
GROOVY-12569: SC: do not name a package-private class of another GroovyClassLoader compilation in bytecode #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 GROOVY-12484: STC: method and constructor calls on an inaccessible ty… #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 GROOVY-12570: let super.m() reach a package-private method of a superclass of another class loader #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?

# Conflicts: # COMPATIBILITY.md

testlens-app · 2026-11-04T03:15:18Z

✅ All tests passed ✅

🏷️ Commit: bead3ad
▶️ Tests: 124099 executed
⚪️ Checks: 27/27 completed

Learn more about TestLens at testlens.app/docs.

codeconsole added 15 commits October 29, 2026 11:42

This was referenced Oct 30, 2026

GROOVY-12569: SC: do not name a package-private class of another GroovyClassLoader compilation in bytecode #3098

Open

GROOVY-12570: let super.m() reach a package-private method of a superclass of another class loader #3099

Open

codeconsole mentioned this pull request Oct 30, 2026

GROOVY-12488: SC: call the constructor of a constructor reference directly #3022

Merged

daniellansun approved these changes Oct 30, 2026

View reviewed changes

Merge branch 'ctor-ref-a' into ctor-ref-b

7be59ca

blackdrag requested changes Oct 30, 2026

View reviewed changes

Comment thread src/main/java/org/codehaus/groovy/classgen/AsmClassGenerator.java Resolved

codeconsole added 2 commits October 30, 2026 17:27

Merge remote-tracking branch 'origin/master' into ctor-ref-b

5f27450

# Conflicts: # src/main/java/org/codehaus/groovy/classgen/asm/sc/StaticTypesMethodReferenceExpressionWriter.java

Merge remote-tracking branch 'origin/master' into ctor-ref-b

2b38bca

Merge remote-tracking branch 'origin/master' into ctor-ref-b

93d5776

Merge remote-tracking branch 'origin/master' into ctor-ref-b

bead3ad

# Conflicts: # COMPATIBILITY.md

Navigation Menu

Repository navigation

GROOVY-12568: SC: reach protected and package-private members of a class of another GroovyClassLoader compilation through the meta-class - #3097

GROOVY-12568: SC: reach protected and package-private members of a class of another GroovyClassLoader compilation through the meta-class#3097
codeconsole wants to merge 21 commits into
apache:masterfrom
codeconsole:ctor-ref-b

codeconsole commented Oct 30, 2026

Uh oh!

codecov-commenter commented Oct 30, 2026 •

edited

Loading

Uh oh!

daniellansun left a comment

Uh oh!

daniellansun commented Oct 30, 2026

Uh oh!

codeconsole commented Oct 30, 2026

Uh oh!

Uh oh!

codeconsole commented Oct 31, 2026

Uh oh!

blackdrag commented Oct 31, 2026 •

edited

Loading

Uh oh!

codeconsole commented Oct 31, 2026

Uh oh!

blackdrag commented Oct 31, 2026

Uh oh!

codeconsole commented Nov 1, 2026

Uh oh!

testlens-app Bot commented Nov 4, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

codeconsole commented Oct 30, 2026

Tests

Uh oh!

codecov-commenter commented Oct 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

daniellansun left a comment

Choose a reason for hiding this comment

Uh oh!

daniellansun commented Oct 30, 2026

Uh oh!

codeconsole commented Oct 30, 2026

Uh oh!

Uh oh!

codeconsole commented Oct 31, 2026

Uh oh!

blackdrag commented Oct 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codeconsole commented Oct 31, 2026

Uh oh!

blackdrag commented Oct 31, 2026

Uh oh!

codeconsole commented Nov 1, 2026

Uh oh!

testlens-app Bot commented Nov 4, 2026

✅ All tests passed ✅

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

codecov-commenter commented Oct 30, 2026 •

edited

Loading

blackdrag commented Oct 31, 2026 •

edited

Loading