[
https://issues.apache.org/jira/browse/GROOVY-12149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095606#comment-18095606
]
James Daugherty commented on GROOVY-12149:
------------------------------------------
I added an example Pull Request for this here:
[https://github.com/apache/groovy/pull/2690]
> Nondeterministic reflection order flows into generated bytecode, breaking
> reproducible builds
> ---------------------------------------------------------------------------------------------
>
> Key: GROOVY-12149
> URL: https://issues.apache.org/jira/browse/GROOVY-12149
> Project: Groovy
> Issue Type: Bug
> Reporter: James Daugherty
> Priority: Major
>
> Follow-up to GROOVY-12146, which fixed nondeterministic ordering of
> annotation members copied from precompiled classes. The same root cause —
> Class.getDeclaredMethods()/getDeclaredFields()/getDeclaredConstructors()
> returning members in an unspecified order that varies between HotSpot runs —
> also affects Java8#configureClassNode, which populates ClassNodes for
> precompiled classes via reflection. The enumeration order is preserved
> through to bytecode generation (e.g. via the LinkedHashMap returned by
> ClassNode#getDeclaredMethodsMap), so two compilations of identical sources on
> the same JDK can still produce byte-different class files.
> Two manifestations were observed while verifying the reproducibility of the
> Apache Grails 8.0.0-M3 release artifacts (same sources, same JDK,
> containerized double-build):
> 1. MOP bridge methods: for classes extending a precompiled Groovy class,
> MopWriter#getSuperMethods iterates the superclass's declared-methods map, so
> the synthetic super$N$… methods are emitted in a different order per build.
> 2. Woven trait methods: methods copied from a precompiled trait (e.g. GORM's
> DirtyCheckable#trackChanges/syncChangedProperties) are woven into
> implementing classes in enumeration order, reordering the emitted methods and
> the constant pool.
> In both cases the bytecode is semantically identical — decompiled sources
> match exactly — only member emission order (and the constant-pool layout that
> follows from it) differs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
