[
https://issues.apache.org/jira/browse/GROOVY-11715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18008560#comment-18008560
]
Paul King edited comment on GROOVY-11715 at 7/20/25 11:39 PM:
--------------------------------------------------------------
With the re-roll, I actually backed the change out of 5.0.0-beta-2 (it is in
4.0.28) and tried a different approach of removing the maps altogether and
instead tried to process annotation attributes in exactly the order they are
encountered. I expect from past experiences that won't be enough for Grails but
may make it easier to track the original source of non-determinism. We might
need to do more work on the Groovy 5 branch before Grails swaps to Groovy 5.
was (Author: paulk):
With the re-roll, I actually backed the change out of 5.0.0-beta-2 (it is in
4.0.28) and tried a different approach of removing the maps altogether and
instead tried to process in exactly the order they are encountered. I expect
from past experiences that won't be enough for Grails but may make it easier to
track the original source of non-determinism. We might need to do more work on
the Groovy 5 branch before Grails swaps to Groovy 5.
> Grails reproducible build part 3: @DelegatesTo ordering
> -------------------------------------------------------
>
> Key: GROOVY-11715
> URL: https://issues.apache.org/jira/browse/GROOVY-11715
> Project: Groovy
> Issue Type: Bug
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
> Fix For: 4.0.28
>
>
> We have fixed a few previous issues. This is the last remaining one that we
> know of. The symptoms are that on subsequent builds of the Grails project,
> the order in which annotation attributes are written into the bytecode
> varies, e.g.:
> {code:groovy}
> public void render(@groovy.lang.DelegatesTo(
> strategy = 1,
> type = "",
> value = groovy.lang.DelegatesTo.Target.class,
> target = "",
> genericTypeIndex = -1) groovy.lang.Closure closure) { /* compiled code */
> }
> {code}
> vs
> {code:groovy}
> public void render(@groovy.lang.DelegatesTo(
> strategy = 1,
> genericTypeIndex = -1,
> type = "",
> value = groovy.lang.DelegatesTo.Target.class,
> target = "") groovy.lang.Closure closure) { /* compiled code */ }
> {code}
> While these are logically equivalent, the arbitrary ordering hinders
> reproducibility.
> Unlike the previous cases where we understood where the non-determinism was
> probably coming from, here we haven't tracked down the root cause.
> Never-the-less, it seems worth tackling the symptoms for now and we can
> always back out the current changes if we can find a more direct fix. We
> originally changed HashMap => LinkedHashMap but that didn't seem to be
> enough, hence the change to TreeMap. I'd like to eventually move back to
> LinkedHashMap.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
