[
https://issues.apache.org/jira/browse/GROOVY-12431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Przemek Bielicki updated GROOVY-12431:
--------------------------------------
Priority: Minor (was: Major)
> Backport GROOVY-12149 (sorted reflection in Java8#configureClassNode) to 4.0.x
> ------------------------------------------------------------------------------
>
> Key: GROOVY-12431
> URL: https://issues.apache.org/jira/browse/GROOVY-12431
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 4.0.33
> Reporter: Przemek Bielicki
> Priority: Minor
>
> GROOVY-12149 (fixed in 5.0.8 and 6.0.0-beta-1 by
> https://github.com/apache/groovy/pull/2690) makes
> {{Java8#configureClassNode}} read members in a sorted order instead of
> {{getDeclaredMethods()}} order. The 4.0.x line still has the unsorted loops:
> in 4.0.33, {{configureClassNode}} iterates {{clazz.getDeclaredFields()}},
> {{clazz.getDeclaredMethods()}} and {{clazz.getDeclaredConstructors()}} as
> returned.
> We see non-reproducible output on 4.0.33 in CI that is consistent with this.
> A class implements a trait that is compiled in a separate module and consumed
> as a jar:
> {code:groovy}
> // module A, on module B's compile classpath as a jar
> trait SharedTrait {
> boolean hasFeature() { ... }
> String describeFeature(int index = 0) { ... }
> }
> // module B
> class ItemModule extends BaseModule implements SharedTrait {
> }
> {code}
> Gradle compiles the implementing module in a long-lived Groovy compiler
> daemon. Across CI agents, identical compile inputs (as Gradle fingerprints
> them: sources, compile classpath, Groovy and JDK versions) produce more than
> one version of this class: over two days, 13 distinct sets of inputs each
> produced at least two different outputs. In the pair we inspected, the only
> differing file is this class, the one that weaves in the precompiled trait's
> methods, which is the second case described in GROOVY-12149.
> This matters for us because the compile task caches by its inputs: builds
> that execute it concurrently push different outputs under one cache key, and
> every downstream task fingerprinting those classes then misses the build
> cache.
> The PR is small (ReflectionUtils +66, Java8 +3/-7). Could it be backported to
> GROOVY_4_0_X for the next 4.0.x release?
> A second observation, possibly the same cause but unconfirmed: on 4.0.33 the
> anonymous subclasses generated for enum constants with class bodies
> ({{MyEnum$1}}, {{MyEnum$2}}) also compiled to different bytes across CI
> agents under identical inputs. Recompiling that module repeatedly in fresh
> JVMs locally, including with randomized identity hash codes, always gave
> identical output, which would fit an order that depends on the JVM's
> class-loading history. We have not obtained both byte variants yet, so we
> cannot say whether the difference is member ordering. We can try to produce
> them if that would help.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
