[ https://issues.apache.org/jira/browse/COLLECTIONS-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838246#comment-13838246 ]
Thomas Neidhart commented on COLLECTIONS-504: --------------------------------------------- Unfortunately this would only be possible for an immutable CompositeMap. If there is a mutator defined, it would be possible that an unexpected type may appear in a composited map, e.g. {noformat} Map<String, String> map1 = new HashMap<String, String>(); Map<String, Object> map2 = new HashMap<String, Object>(); map1.put("key1", "value1"); map2.put("key2", Integer.valueOf(1)); CompositeMap<String, Object> composite = new CompositeMap<String, Object>(map1, map2, new CompositeMap.MapMutator<String, Object>() { public Object put(CompositeMap<String, Object> map, Map<String, Object>[] composited, String key, Object value) { return composited[1].put(key, value); } }); composite.put("key3", Integer.valueOf(2)); for (Map.Entry<String, String> entry : map1.entrySet()) { System.out.println(entry.getValue()); } {noformat} will result in {noformat} Exception in thread "main" java.lang.ClassCastException: java.lang.Integer {noformat} So I do not think that this is a good idea unless we add Immutable versions of various collection types similar to what guava does. > CompositeMap should support compositing of maps of derived types > ---------------------------------------------------------------- > > Key: COLLECTIONS-504 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-504 > Project: Commons Collections > Issue Type: Bug > Components: Map > Affects Versions: 4.0 > Reporter: Peter Cooper Jr. > Priority: Minor > > I'm attempting to composite two maps, one of which is a {{Map<String, > String>}} and the other of which is a {{Map<String, Object>}}. I would have > expected that I could composite them into a {{CompositeMap<String, Object>}}, > but the constructors of CompositeMap expect all of the maps being composited > to have exactly the same type arguments. > That is, I think the constructors should take arguments of {{Map<? extends K, > ? extends V>}} instead of what they currently have of {{Map<K, V>}}, much > like most collection methods, since there shouldn't be a problem accepting > type arguments that are subtypes of the composite map types. > Thanks! -- This message was sent by Atlassian JIRA (v6.1#6144)