Generics revisited - questions

[Rod Widdowson]

That creaking sound you hear is a can of worms opening.

In my travels I happened upon a use of the now deprecated SpringSupport.newContext( ) (in
net.shibboleth.idp.installer.ant.MetadataGeneratorTask).  You might want to open that up (as well as
net.shibboleth.idp.spring.IdPPropertiesApplicationContextInitializer) before reading any further.

In this case we are actually injecting an ApplicationContextInitializer (we do this since we want to use the properties to get at
the configured certificates).  So I want to add a call to     setContextInitializers(). The signature for this is that it takes a 

List<ApplicationContextInitializer<? super FilesystemGenericApplicationContext>>

Which I get, we really want to encourage use of our FilesystemGenericApplicationContext throughout the stack.  My problem is that
the initializer I need is derived from 

net.shibboleth.idp.spring.IdPPropertiesApplicationContextInitializer

which is declared as

implements ApplicationContextInitializer<ConfigurableApplicationContext>

So things degenerate pretty quickly (ConfigurableApplicationContext being a subtype of FilesystemGenericApplicationContext not a
super type).

I'm wondering what we should do about this?  The options I can think of are

1) Ignore it, and put in a case to make IdPPropertiesApplicationContextInitializer implement ApplicationContextInitializer<
FilesystemGenericApplicationContext>> in V4
2) Change the signature of setContextInitializers (it isn't use anywhere else)
3) Bodge it.

The last is troubling in that I don't know why but if I go

final ApplicationContextInitializer<ConfigurableApplicationContext>  initializer = new Initializer();
final List<ApplicationContextInitializer<? super FilesystemGenericApplicationContext>> list = new ArrayList<>(1);
list.add(initializer);

Then this list is now of the correct type and I can pass it to setContextInitializers.  This all compiles file

Actually I need to do go via a list anyway since Collections.singletonList() doesn't do the correct thing even when passed a
ApplicationContextInitializer<FilesystemGenericApplicationContext>>.  So there's another question: why?

The final question is whether it might be an idea to go in and systematically remove the last three places that still use the
deprecated constructor?

Rod