[
https://issues.apache.org/jira/browse/GROOVY-11058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723129#comment-17723129
]
Jim Klimov commented on GROOVY-11058:
-------------------------------------
Yes, the {{plus()}} method making a new object is correct; just the object's
type here (and as a consequence - constraints applied) is not correct.
FWIW, in my custom class where I stumbled on this issue while conjuring
use-cases and unit tests, the operator is simply defined as a clone+leftShift:
{code:java}
public synchronized Map plus(Map.Entry entry) {
TypedFirstMap newMap = this.clone()
return newMap.leftShift(entry)
}
public synchronized Map leftShift(Map.Entry entry) {
this.put(entry.getKey(), entry.getValue())
return this
}
public synchronized Map plus(Map other) {
TypedFirstMap newMap = this.clone()
return newMap.leftShift(other)
}
public synchronized Map leftShift(Map other) {
other.each { def key, def value ->
this.put(key, value)
}
return this
}{code}
...calling out to a very custom {{put()}} implementation for that use-case.
> 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)
