On 02/02/2015 11:26, Chris Hegarty wrote:
I agree with Alan, addURLStreamHandlerFactory is probably an
attractive nuisance. It is not strictly necessary to achieve the goal
here; replace the problematic ( with modules ) system property with a
service lookup.
For now, I'd like to move this iss
On Feb 2, 2015, at 12:34 PM, Chris Hegarty wrote:
> On 02/02/15 11:00, Paul Sandoz wrote:
>>
>> On Jan 30, 2015, at 10:10 PM, Alan Bateman wrote:
>>
>>> On 30/01/2015 15:35, Chris Hegarty wrote:
:
Update webrev and spec diffs:
http://cr.openjdk.java.net/~chegar/8064924
On 02/02/15 11:00, Paul Sandoz wrote:
On Jan 30, 2015, at 10:10 PM, Alan Bateman wrote:
On 30/01/2015 15:35, Chris Hegarty wrote:
:
Update webrev and spec diffs:
http://cr.openjdk.java.net/~chegar/8064924/01/
I think the javadoc looks much better now, thanks.
Minor comments in URL:
I agree with Alan, addURLStreamHandlerFactory is probably an attractive
nuisance. It is not strictly necessary to achieve the goal here; replace
the problematic ( with modules ) system property with a service lookup.
For now, I'd like to move this issue forward without the additional new
publi
On Jan 30, 2015, at 10:10 PM, Alan Bateman wrote:
> On 30/01/2015 15:35, Chris Hegarty wrote:
>> :
>>
>> Update webrev and spec diffs:
>>http://cr.openjdk.java.net/~chegar/8064924/01/
>>
> I think the javadoc looks much better now, thanks.
>
Minor comments in URL:
Java doc on URL constr
Just catching up…
On 2 Feb 2015, at 08:42, Alan Bateman wrote:
> On 01/02/2015 10:45, Peter Levart wrote:
>> :
>>
>> I see. But if URLStreamHandlerFactories are only supposed to be located via
>> the system class loader, is that different from what we have now when
>> URLStreamHandlers are be
On 01/02/2015 10:45, Peter Levart wrote:
:
I see. But if URLStreamHandlerFactories are only supposed to be
located via the system class loader, is that different from what we
have now when URLStreamHandlers are being located directly via class
name construction (prefix + protocol + .Handler)
