You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Thomas Neidhart (JIRA)" <ji...@apache.org> on 2013/12/03 23:08:36 UTC

[jira] [Commented] (COLLECTIONS-504) CompositeMap should support compositing of maps of derived types

    [ 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)