RFR 8064924: Update java.net.URL to work with modules

[Peter Levart]

On 02/04/2015 02:54 PM, Chris Hegarty wrote:
> On 02/02/15 20:52, Alan Bateman wrote:
>> ....
>> I'm happy with this approach. One outstanding point from the discussion
>> is whether the URLStreamHandlerFactory implementation will need to be
>> granted RuntimePermission("setFactory"), if so then this will need to go
>> into the javadoc.
>
> I think that we should check "setFactory" for providers located
> by service loader. The most appropriate way to do this is with
> a new public abstract type who's constructor checks this,
> similar to CharsetProvider ( and others ).
>
> The updated spec revision, link below, defines the new public
> provider type in a new networking service provider interface
> package, java.net.spi. Future service provider interfaces for
> the java.net package should be defined into this package.
>
>
> http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html 
>
>
> Note:
>  The spec does no mention what happens when a SecurityException is
>  thrown ( it will be the cause of the SCE ). The prototype
>  implementation I have will will swallow it, and continue searching,
>  as is done for CharsetProviders. A SecurityException, locating
>  a provider, should not prevent the the app from making progress.
>  The provider will just not be available.
>
> -Chris.

Hi Chris,

I agree that this is the most appropriate way with which you can force 
some provider's class code (the constructor) in the call stack so that 
you get correct AccessControlContext to check against. But the name 
starts to sound like German words. :-)

Wouldn't URLStreamHandlerProvider be enough? Since it's a provider for 
URLStreamHandlers and not URLStreamHandlerFactories.


Regards, Peter