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

2015-01-30 Thread Chris Hegarty
Thanks for the comments Alan… On 30 Jan 2015, at 14:32, Alan Bateman alan.bate...@oracle.com 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

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

2015-01-30 Thread Alan Bateman
On 30/01/2015 12:18, Seán Coffey wrote: Alan, hadn't spotted the race issue. I guess we could delay setting ver_initialized until OSVERSIONINFO is populated. Alternatively - like you say, I think we can revert back to the simpler edit :

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

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

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

2015-01-30 Thread Seán Coffey
Thanks all - Agreed changes pushed to 7u85 and I'll make a request to see if we can include this in 7u80 code base. regards, Sean. On 30/01/2015 16:00, Alan Bateman wrote: On 30/01/2015 12:18, Seán Coffey wrote: Alan, hadn't spotted the race issue. I guess we could delay setting

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

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

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

2015-01-30 Thread Valery Kopylov (Akvelon)
From: Seán Coffey [mailto:sean.cof...@oracle.com] Alan, hadn't spotted the race issue. I guess we could delay setting ver_initialized until OSVERSIONINFO is populated. Alternatively - like you say, I think we can revert back to the simpler edit :

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

2015-01-30 Thread Seán Coffey
Alan, hadn't spotted the race issue. I guess we could delay setting ver_initialized until OSVERSIONINFO is populated. Alternatively - like you say, I think we can revert back to the simpler edit : http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v2/webrev/ I'll run with this version