> From: Alan Bateman <alan.bate...@oracle.com> > The javadoc for the 4-arg URL constructor has all the details on how it > interacts with the system-wide stream handler factory, also how the > system class loader is used to locate protocol handlers that are > intended to used system-wide (this includes the ability to override > non-core protocol handlers). I've no doubt that this won't be exactly > what you want but I hope you can see how URLStreamHandlerProvider is > used as the service type.
I don't think service loader lookup is going to help us here. Each framework instance will need its own provider but the set of providers will be constant to what is discovered on the system class loader. As additional frameworks come up their providers will have no chance to be discovered. Furthermore each framework implementation can be loaded by a non-system class loader. For the usecase I am concerned about the framework implementation will not be loaded by the system class loader but instead by some dynamic class loader that can be thrown away when the framework instance is torn down. For Eclipse a small launcher is the only jar on the system class loader. The framework itself is loaded with a custom class loader the launcher creates. It appears we will have to continue to rely on the static methods to set our factory instances. > > There are also updates to allow ContentHandlerFactory implementations be > deployed as modules. The details on that are in the javadoc for > URLConnection::getContent. This one did not need introducing a new > service type. I have not been able to determine why an SPI is needed for providing URLStreamHandlerFactory implementations to the service loader but not for ContentHandlerFactory implementations. The URLStreamHandlerProvider is just an empty abstract class that implements URLStreamHandlerFactory. Why couldn't the provider type just be URLStreamHandlerFactory directly similar to how ContentHandlerFactory is? Thanks for your time. Tom
