commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Neidhart (JIRA)" <>
Subject [jira] [Commented] (COLLECTIONS-504) CompositeMap should support compositing of maps of derived types
Date Tue, 03 Dec 2013 22:08:36 GMT


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.

        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()) {

will result in

Exception in thread "main" java.lang.ClassCastException: java.lang.Integer

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:
>             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

View raw message