[
https://issues.apache.org/jira/browse/GROOVY-11715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18007946#comment-18007946
]
ASF GitHub Bot commented on GROOVY-11715:
-----------------------------------------
daniellansun commented on PR #2267:
URL: https://github.com/apache/groovy/pull/2267#issuecomment-3086021765
+1
> 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
>
> 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)
