The other problem is that (IIUC) the ServiceLoader pattern was intended for simple services that either dont need to connect to the environment they are working within or explicitly have initialization as part of the SPI. Where the SPI is agnostic about initialization and context, leaning towards pure IoC like patterns it falls to the SPI implementation to acquire context through out of band or other means. What would be really nice is to see a RFC that enabled a SPI implementation to be a declaratively managed component, living in a separate bundle, where it gained access to a protected set of SPI and support classes within the SPI consumer bundle. I think I am right in saying that would require the declarative service manager to pre-bind to the SPI consumer classloader before instancing the SPI implementation, so that the SPI classes from the correct classloader were already available?

It is good to see Aries addressing these issues and looking at RFC 167 it certainly looks like its going to address the ServiceLocator pattern, which continues to be the bain of anyone integrating 3rd part components in OSGi. Its almost become a standard pattern in my code bases to set the context classloader to the bundle classloader in advance of performing initialisation of anything not designed for OSGi.