> 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.