On May 19, 2013, at 3:25 PM, Adrian Crum <adrian.c...@sandglass-software.com> wrote:
> In addition, I fixed a flaw in the GenericEntity/GenericValue classes that > allowed other threads to modify a shared instance that was supposed to be > immutable. This is a serious problem because it is common practice to cast a > Generic Entity to a java.util.Map, then pass it on to various methods - with > the result that in some remote corner of the project a method thinks it is > modifying a Map, but in reality it is modifying a supposedly immutable > GenericEntity. Adrian, all, how would you recommend to check and spot for existing code that may modify the content of objects now immutable? Here I am considering both ootb code and custom code that is running on one of the release branches where these fixes have been backported. The purpose of this message is to find out the best ways to spot the issues that a custom instance may have after an update to the next release: should we recommend to search for some patterns while doing static code analysis? Considering that the client code may be written in Java, Groovy, Minilang etc... it may be difficult to define some good patterns. Any ideas? Of course testing the screens/code is also a good way to spot these issues, but sometimes this is not a viable option. Should we document this in Confluence (also with suggested ways of fix the code)? Thanks, Jacopo
