[
https://issues.apache.org/jira/browse/GROOVY-11058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723004#comment-17723004
]
Jochen Theodorou commented on GROOVY-11058:
-------------------------------------------
[~jimklimov] If you want to add something to a collection without creating a
new collection you should use "<<". "a+=b" is the same as "a = a +b".
Accordingly:
{code:Java}
def m1 = [m:1]
def m2 = m1
m2 += [n:1]
assert m1 == [m:1]
assert m2 == [m:1, n:1]
{code}
maybe it could be seen as a bug, that the result class for m2 is a
LinkedHashMap, instead of the origin type, but not that a new instance is
created - that part is by design. And it is a new instance, not a
modification, as my example shows.
So is this bug report only about the result class of m2 then?
> plus() on UnmodifiableMap returns a new Map with changed data
> -------------------------------------------------------------
>
> Key: GROOVY-11058
> URL: https://issues.apache.org/jira/browse/GROOVY-11058
> Project: Groovy
> Issue Type: Bug
> Components: Groovy Console
> Affects Versions: 2.4.21, 2.5.14, 3.0.9, 4.0.12
> Reporter: Jim Klimov
> Priority: Major
>
> {color:#172b4d}Groovy UnmodifiableMap.plus() operations return a different
> Map class and modified data in the object, compromising common syntax like
> {{myView += myMap}} (which can happen e.g. during script refactoring from
> maps to read-only views and *should* throw when misused).{color}
> Originally found in Jenkins with its built-in old groovy-2.4.21 (in-core for
> pipeline scripts) and [http://tpcg.io/_R7VESY], but verified with a newer
> 2.5.14 version at e.g.
> [https://groovyconsole.appspot.com/script/4819062429319168] (see "Output" tab
> since it shows stack trace by default) and groovy-3.0.9/jvm-17.0.1 as seen at
> [https://jdoodle.com/ia/HVH] and double-checked locally with GroovyConsole
> from a freshly fetched 4.0.12 tarball.
>
> {code:java}
> // Repro case for Groovy
> println GroovySystem.version
> def m1 = [t: 'somestring', n: 1]
> def m2 = Collections.unmodifiableMap(m1) // returns an @UnmodifiableView
> decorated Map
> println m1.getClass() // AS EXPECTED: class java.util.LinkedHashMap
> println m2.getClass() // AS EXPECTED: class
> java.util.Collections$UnmodifiableMap
> // NOTE: plus() operations return a different class and modified data:
> m2 += [m:2]
> //m2 = m2 + [m:2]
> println m2.getClass() // NOT AS EXPECTED: class java.util.LinkedHashMap
> println m2 // NOT AS EXPECTED: [t:somestring, n:1, m:2]
> // NOTE: Direct operations on the view (put, putAll, replace, remove,
> // leftShift and << operator) are constrained as expected:
> def m3 = Collections.unmodifiableMap(m1)
> //m3.putAll([m:2])
> m3 << [m:2]
> // THROWS AS EXPECTED: java.lang.UnsupportedOperationException ...
> {code}
> With typical output like this:
> {code:java}
> 2.5.14
> class java.util.LinkedHashMap
> class java.util.Collections$UnmodifiableMap
> class java.util.LinkedHashMap
> [t:somestring, n:1, m:2]
> java.lang.UnsupportedOperationException
> at Script1.run(Script1.groovy:20){code}
> For clarity, the expectation is that the "view" map {{m2}} remains
> unmodifiable throughout the additions and other manipulations. I suppose that
> {{Collections$UnmodifiableMap}} should but does not override the {{plus()}}
> method in Groovy terms, but this is just an unverified educated guess based
> on another custom Map type I was making.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
