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

[Peter Levart]

On 02/04/2015 05:19 PM, Chris Hegarty wrote:
> On 04/02/15 16:01, Peter Levart wrote:
>> On 02/04/2015 04:45 PM, Alan Bateman wrote:
>>> On 04/02/2015 15:10, Weijun Wang wrote:
>>>> It should be checked, otherwise a non-initialized parent object comes
>>>> into being.
>>> In general then permission checks in constructors are a bad idea but
>>> we have an established idiom that has the no-arg constructor invoking
>>> a static method that does the permission check.
>>>
>>> -Alan
>>
>> There is an alternative. The
>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(Class<?>) 
>>
>> checks the permission without running any code of the class.
>
> I did look at checking the permission of the impl class, but with 
> service loader this would have to be done after the instance is 
> created, which in itself should not be a big issue here as the 
> provider would not be used by java.net.URL, but the side-effect is 
> that we end up creating an instance that will not be used.
>
> > But if
>> verify-er checks constructor flow then this is as good as proposed.
>
> I am happy that the verifier will catch this. This is an established 
> idiom that has been used in other, more sensitive, areas.
>
> I'll see if I can prove this with an out-of-order compilation, or 
> something.
>
> -Chris.
>

The idiom with constructor is also more correct from security standpoint 
as all the constructors in class hierarchy are on the call-stack when 
the check is made. If particular classes from the hierarchy have 
separate protection domains, the check covers all of them and that's 
correct since code from any or all of them could be involved in later 
URL constructions.

Peter