I'm not sure I see the benefit, but I'm not always spot-on when it comes to wildcards in collections...
Does the change mean that you're allowed to pass a Map<String, String> to this without casting, whereas before you couldn't? The common use-cases here all have a heterogeneous value type (because of "embedded"), so if I'm understanding this correctly, I don't see the benefit of this change. (BTW, I thought that in fact was possible to add elements to "? super ...", just not "? extends ...".) -- Adam On 9/13/07, Simon Lessard <[EMAIL PROTECTED]> wrote: > Hello, > > I would like to do a public API change to Icon's renderIcon method and its > dependencies. Currently the signature is > > abstract public void renderIcon( > FacesContext context, > RenderingContext arc, > Map<String, Object> attrs > ) throws IOException; > > I would like to change that to the following to make it easier to call > because of non covariance of generic collections. > > abstract public void renderIcon( > FacesContext context, > RenderingContext arc, > Map<String, ? extends Object> attrs > ) throws IOException; > > I don't think it'll break anything as it's a generalization of the previous > signature, meaning all old code should still be able to call the method > without any change. The only implication is that renderIcon and its > dependencies will no longer be able to alter the map since it's quite > impossible to add an element to a collection containing a wildcard. It's not > in the method contract to alter the attribute map though, so it should not > be an issue. However, as it's a public API change, I preferred to ask on the > mailing list in case I oversaw something. > > > Regards, > > ~ Simon >
