Ugly things done to support multiple ContentHandlerFactory and URLStreamHandlerFactory

[Alan Bateman]

On 13/10/2016 19:40, Thomas Watson wrote:

>
> 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.
I should have been clearer. I was trying to point out that you can 
locate URLStreamHandlerProvider implementations that aren't built-in or 
deployed on the class path yourself. That should be enough to create the 
URLStreamHandler and do the wrapping that I think you are doing.

> :
>
> 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?
This is a security sensitive area and the permission check needed here 
couldn't be reliably enforced if the interface URLStreamHandleFactory 
were the service type. There is discussion on net-dev where this point 
was discussed.

Speaking of net-dev, then maybe this thread should move there as this 
topic is really more of a URL issue rather than module system issue.

-Alan