RE: Backporting the TCP loopback fast path (Windows) improvement to OpenJDK v7

2015-01-31 Thread Martin Sawicki (MS OPEN TECH)
Thank you all for the help! From: Seán Coffey [mailto:sean.cof...@oracle.com] Sent: Friday, January 30, 2015 12:07 PM To: Alan Bateman; Valery Kopylov (Akvelon); Martin Sawicki (MS OPEN TECH); jdk7u-...@openjdk.java.net Cc: OpenJDK Network Dev list; Kirk Shoop (MS OPEN TECH) Subject: Re: Backport

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

2015-01-31 Thread Peter Levart
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

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

2015-01-31 Thread Alan Bateman
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

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

2015-01-31 Thread Peter Levart
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

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

2015-01-31 Thread Bernd
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