[
https://issues.apache.org/jira/browse/GROOVY-11715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18008178#comment-18008178
]
ASF GitHub Bot commented on GROOVY-11715:
-----------------------------------------
matrei commented on code in PR #2267:
URL: https://github.com/apache/groovy/pull/2267#discussion_r2217020381
##########
src/main/java/org/codehaus/groovy/classgen/AsmClassGenerator.java:
##########
@@ -2221,10 +2222,11 @@ private AnnotationVisitor getAnnotationVisitor(final
AnnotatedNode targetNode, f
* @param av the visitor to use
*/
public void visitAnnotationAttributes(final AnnotationNode an, final
AnnotationVisitor av) {
- Map<String, Object> constantAttrs = new HashMap<>();
- Map<String, PropertyExpression> enumAttrs = new HashMap<>();
- Map<String, Object> atAttrs = new HashMap<>();
- Map<String, ListExpression> arrayAttrs = new HashMap<>();
+ // GROOVY-11715 TODO If we can determine what was causing the issues
mentioned on that ticket, we should change these back to LinkedHashMap
Review Comment:
@paulk-asert Would a plausible explanation to why `LinkedHashMap` isn't
working be that the items are inserted into the maps in different order across
different runs? As `LinkedHashMap` maintains insertion order.
> 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: 5.0.0-beta-2
>
>
> 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)
