RFR 8064924: Update java.net.URL to work with modules
Peter Levart
peter.levart at gmail.com
Wed Feb 4 14:38:43 UTC 2015
On 02/04/2015 03:29 PM, Peter Levart wrote:
> 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
>
>
Just a thought,...
Is JVM bytecode verifier checking that a constructor chains to super
constructor? If yes, we are ok. If not, specially crafted bytecode could
skip security checks.
Peter
More information about the net-dev
mailing list