sbglasius opened a new issue, #16290: URL: https://github.com/apache/grails-core/issues/16290
Split out from review discussion on https://github.com/apache/grails-core/pull/16281. ## Background Groovy 5 changed runtime method selection for classes implementing `Map`. For a `String` subscript key, `DefaultGroovyMethods.getAt(Object, String)` (→ `getProperty`) now wins over `getAt(Map, Object)` (→ `get`), and likewise `putAt(Object, String, Object)` (→ `setProperty`) over `putAt(Map, K, V)`. The consequence is that on a `Map` implementation that also exposes a no-arg getter, an entry whose key matches that getter's property name becomes unreachable by subscript and by property access — and writing it either throws `ReadOnlyPropertyException` or silently drives the property instead of the map. #16280 fixed this for `AbstractTypeConvertingMap`, which covers `GrailsParameterMap` (`params`) and `GroovyPageAttributes` (`attrs`), by declaring `getAt(String)` / `putAt(String, Object)` and map-first `getProperty` / `setProperty`. ## Scope of this issue The same shape exists elsewhere in the codebase and has not been assessed: - `LazyMetaPropertyMap` — `implements Map`, exposes `public Object getInstance()`, so an entry named `instance` is affected - `DirtyCheckingMap` - `JSONObject` Each needs checking for whether it exposes no-arg getters that collide with plausible keys, and whether the same remedy applies or the collision is not reachable in practice. Worth also sweeping for other `implements Map` classes with no-arg getters rather than assuming these three are the complete set. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
