Hi Ichiro,
in fact, PluginManager#parseArgs builds a HashMap<String, Object> but
returns an
ungenerified Map, most probably because this way binary compatibility with
older,
ungenerified plugins is ensured. Besides, as the plugin system hasn't had
any issues
since a long long time, the focus had been put elsewhere.
But yes, aside from the compatibility issue, constraining to <String,
Object> makes
sense to me, as most probably this is how the Map is used by everyone
(anyone not
doing this way please correct me).
hmm right now I'm thinking that WikiPlugin's signature could be changed to
something like:
public interface WikiPlugin <K, V> {
public String execute( WikiContext context, Map<K,V> params ) throws
PluginException;
}
so you could override the Map types on your plugins. Makes sense?
br,
juan pablo
On Sat, Nov 3, 2012 at 10:23 AM, Ichiro Furusato
<ichiro.furus...@gmail.com>wrote:
> Hi,
>
> In looking at the 2.9.0 code I note that it doesn't use generics in a
> number of
> rather key places, such as WikiPlugin.execute(), so I'm guessing it hasn't
> been updated in a few years (at least in that regard), perhaps due to the
> somewhat longstanding status of the project going into Apache, or for
> legacy-
> compatibility reasons.
>
> Could someone please fill me in as to any particular reason why the Map
> argument couldn't be constrained to <String,String> or <String,Object>?
> I've
> got quite a few plugins that are now incompatible with a generics-less
> WikiPlugin API, i.e.,
>
> public String execute( WikiContext context, Map<String,Object>
> params ) throws PluginException;
>
> ...and rather than remove all my generics I'm wondering if it'd be possible
> to update the API. Yes, I know that is a brash assumption.
>
> Thanks much,
>
> Ichiro
>
