This issue addresses a findbugs issue:
org.apache.commons.collections.map.MultiKeyMap.clone() does not call super.clone()
The current clone() implementation creates a new MultiKeyMap instance. This will lead to problems when clone() is invoked on subclasses of MultiKeyMap. This is a corresponding junit test which fails:
Instead of creating a new MultiKeyMap instance, the clone() method should invoke super.clone() which leads in Object.clone(). This always returns an object of the correct type.
For serialisation compatibilty reasons to commons collections V.3.2, MultiKeyMap contains a map reference (the decorated map) which hides the same field in the super class AbstractMapDecorator. This is quite 'ugly' to understand and maintain.
Should we consider to break the compatibility to the 3.2 version?