[jira] [Created] (GROOVY-12159) Synthetic class-literal fields and accessors are emitted in hash order, not the order the literals were encountered

["Paul King (Jira)" <ji...@apache.org>]

Paul King created GROOVY-12159:
----------------------------------

             Summary: Synthetic class-literal fields and accessors are emitted in hash order, not the order the literals were encountered
                 Key: GROOVY-12159
                 URL: https://issues.apache.org/jira/browse/GROOVY-12159
             Project: Groovy
          Issue Type: Improvement
            Reporter: Paul King
            Assignee: Paul King


h2. Description

{{AsmClassGenerator}} collects the class literals that cannot be emitted as an {{ldc}} into an unordered map, and iterates it to generate the synthetic helper members:

{code:java}
// AsmClassGenerator.java:284
private final Map<String,ClassNode> referencedClasses = new HashMap<>();

// AsmClassGenerator.java:1857 (visitClassExpression)
String staticFieldName = getStaticFieldName(type);
referencedClasses.put(staticFieldName, type);

// AsmClassGenerator.java:1774 (createSyntheticStaticFields)
for (Map.Entry<String, ClassNode> entry : referencedClasses.entrySet()) {
    ...   // <-- emits the $class$... field and its $get$$class$... accessor
}
{code}

The keys are the synthetic field names, so *the emitted {{$class$...}} fields and their {{$get$$class$...}} accessors appear in the hash order of those names* rather than in the order the class literals were encountered. Both iteration sites are affected: {{createSyntheticStaticFields}} ({{:1774}}) for classes and {{createInterfaceSyntheticStaticFields}} ({{:1758}}) for interfaces.

h3. Reachability

This path is narrow. {{visitClassExpression}} emits an {{ldc}} — and never touches the map — unless {{BytecodeHelper.isClassLiteralPossible(type)}} is false and the type is not in the same compilation unit. That predicate only checks for {{public}}:

{code:java}
// BytecodeHelper.java:660
public static boolean isClassLiteralPossible(ClassNode classNode) {
    return Modifier.isPublic(classNode.getModifiers());
}
{code}

So the map is populated only when a class literal names a *non-public type from another compilation unit*. Ordinary code never reaches it. This is the least impactful of the related ordering issues below, and worth fixing mainly for consistency and because the fix is a single word.

h3. Demonstration

Compilation unit 1:
{code:java}
package p
import groovy.transform.PackageScope
@PackageScope class Ha {}
@PackageScope class Hb {}
@PackageScope class Hc {}
@PackageScope class Hd {}
@PackageScope class He {}
{code}

Compilation unit 2, compiled against the first:
{code:java}
class User {
    def f() { [p.Ha, p.Hb, p.Hc, p.Hd, p.He] }
}
{code}

Reading the emitted {{User.class}} with an ASM {{ClassReader}}, the synthetic members appear as:

{noformat}
fields   : $class$p$Ha, $class$p$Hc, $class$p$Hb, $class$p$He, $class$p$Hd
accessors: $get$$class$p$Ha, $get$$class$p$Hc, $get$$class$p$Hb, $get$$class$p$He, $get$$class$p$Hd
{noformat}

rather than the encounter order {{Ha, Hb, Hc, Hd, He}}.

h3. Impact

The keys are {{String}}s and {{String.hashCode}} is stable, so for a given key set the iteration order is reproducible across JVM runs — this is not by itself a live reproducible-builds failure. It still matters because the emitted order is arbitrary rather than meaningful, and because within a colliding bucket {{HashMap}} chain order follows insertion order, which is the order the literals are visited.

h3. Proposed fix

Use an insertion-ordered map:

{code:java}
private final Map<String,ClassNode> referencedClasses = new LinkedHashMap<>();
{code}

The synthetic fields and accessors are then emitted in the order the class literals were encountered. The member *set* is unchanged — only the order. The map is already {{clear()}}ed per class in {{visitClass}} ({{:355}}), so ordering remains scoped to each class.

h3. Test

{{src/test/groovy/org/codehaus/groovy/classgen/SyntheticClassLiteralFieldOrderTest.groovy}} compiles the {{@PackageScope}} types into a temp directory as one compilation unit, compiles the referencing class as a second unit with that directory on the classpath, then reads the emitted bytes with an ASM {{ClassReader}} and asserts both the {{$class$...}} fields and the {{$get$$class$...}} accessors appear in encounter order. It fails on the current code with {{['Ha', 'Hc', 'Hb', 'He', 'Hd']}} and passes with the fix.

h3. Related

GROOVY-12149 (nondeterministic reflection order flows into generated bytecode). Same class of defect: {{Verifier.addCovariantMethods}} (covariant bridge methods emitted in hash order), {{AutoImplementASTTransformation.getAllCorrectedMethodsMap}} ({{@AutoImplement}} methods emitted in hash order), {{AnnotationCollectorTransform.makeListOfAnnotations}} (annotation member order for precompiled collectors), and GROOVY-12156 ({{chooseBestMethod}} candidates in identity-hash order).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)