On 13 Feb 2015, at 16:11, Alan Bateman wrote:
> On 10/02/2015 16:20, Chris Hegarty wrote:
>> On 10 Feb 2015, at 11:35, Alan Bateman wrote:
>>
>>> On 09/02/2015 14:57, Chris Hegarty wrote:
:
Updated webrev [ spec and implementation] :
http://cr.openjdk.java.net/~chegar/8064
On 10/02/2015 16:20, Chris Hegarty wrote:
On 10 Feb 2015, at 11:35, Alan Bateman wrote:
On 09/02/2015 14:57, Chris Hegarty wrote:
:
Updated webrev [ spec and implementation] :
http://cr.openjdk.java.net/~chegar/8064924/04/
The updated javadoc looks good. I haven't had a chance yet to loo
On 10 Feb 2015, at 11:35, Alan Bateman wrote:
> On 09/02/2015 14:57, Chris Hegarty wrote:
>> :
>>
>> Updated webrev [ spec and implementation] :
>> http://cr.openjdk.java.net/~chegar/8064924/04/
>>
> The updated javadoc looks good. I haven't had a chance yet to look at the
> implementation bu
On 09/02/2015 14:57, Chris Hegarty wrote:
:
Updated webrev [ spec and implementation] :
http://cr.openjdk.java.net/~chegar/8064924/04/
The updated javadoc looks good. I haven't had a chance yet to look at
the implementation but I think you will need to update
/make/common/CORE_PKGS.gmk for
Thank you for the comments Alan.
On 06/02/15 10:20, Alan Bateman wrote:
On 04/02/2015 15:11, Chris Hegarty wrote:
Agreed. Updated in-place
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
I think the approach and naming is good. A few small comments on the
wording
On 04/02/2015 15:11, Chris Hegarty wrote:
Agreed. Updated in-place
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
I think the approach and naming is good. A few small comments on the
wording:
1. "used to locate URLStreamHandlerProvider providers" - the wording
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 const
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 establish
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
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 perm
It should be checked, otherwise a non-initialized parent object comes
into being.
On 2/4/2015 22:38, Peter Levart wrote:
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 securit
Agreed. Updated in-place
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
-Chris.
On 04/02/15 14:44, Alan Bateman wrote:
On 04/02/2015 14:29, Peter Levart wrote:
:
I agree that this is the most appropriate way with which you can force
some provider's class code (t
On 04/02/2015 14:29, Peter Levart wrote:
:
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. :-)
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 RuntimePermi
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 nee
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 sh
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)
On 02/01/2015 10:56 AM, Alan Bateman wrote:
I see. But isn't URL.setURLStreamHandlerFactory() enough for that
purpose? It can only be set once, but there can only be *one*
container that wants it's jar protocol handler configured system-wide.
This a good question as it brings up the scenari
On 02/01/2015 10:56 AM, Alan Bateman wrote:
On 31/01/2015 23:47, Peter Levart wrote:
I agree. Putting the order on the SPI API is not the right solution.
The order should be configured in one place. But there needs to be
some kind of handle each service exposes for order configuration to
re
On 31/01/2015 23:47, Peter Levart wrote:
I agree. Putting the order on the SPI API is not the right solution.
The order should be configured in one place. But there needs to be
some kind of handle each service exposes for order configuration to
reference. So one idea how to extend the Service
Hi Bernd,
On 02/01/2015 01:14 AM, Bernd wrote:
Hello,
What about simply rejecting overlapping programmatic registrations,
This can't work by registering URLStreamHandlerFactory objects as they
don't announce their supported protocols. Perhaps registering
URLStreamHandler objects directly
Hello,
What about simply rejecting overlapping programmatic registrations, and for
the service loader using the natural order (class loader search order). I
guess most extensions register new schemes only, as it was not easy before
in such a central shared system component. an ordering api might n
Hi Alan,
On 01/31/2015 10:33 PM, Alan Bateman wrote:
On 31/01/2015 19:42, Peter Levart wrote:
Hi Chris,
I looked at your solution to make URLStreamHandlerFactory interface a
service provider using ServiceLoader API and in addition adding new
URL static method to programmaticaly register
UR
On 31/01/2015 19:42, Peter Levart wrote:
Hi Chris,
I looked at your solution to make URLStreamHandlerFactory interface a
service provider using ServiceLoader API and in addition adding new
URL static method to programmaticaly register
URLStreamHandlerFactories. There are a couple of issues wi
Hi Chris,
I looked at your solution to make URLStreamHandlerFactory interface a
service provider using ServiceLoader API and in addition adding new URL
static method to programmaticaly register URLStreamHandlerFactories.
There are a couple of issues with your approach I'd like to discuss.
Th
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.
-Alan
Thanks for the comments Alan…
On 30 Jan 2015, at 14:32, Alan Bateman wrote:
> On 30/01/2015 13:36, Chris Hegarty wrote:
>> This is phase 1, of getting java.net.URL work with modules.
>>
>> Being able to effectively specify URL protocol handler factories as fully
>> qualified class names, throu
On 30/01/2015 13:36, Chris Hegarty wrote:
This is phase 1, of getting java.net.URL work with modules.
Being able to effectively specify URL protocol handler factories as fully
qualified class names, through the 'java.protocol.handler.pkgs' system property
is problematic. It requires the protoc
34 matches
Mail list logo
