Hi Alan, Chris, thanks for your help and feedback. It seems my fix was indeed "too optimistic". I've only briefly looked into the errors reported by Chris. The first one is due to a cyclic dependency between Paths.get() and FileSystems.getDefault().
So I've finally decided to go with Alan's proposal which is probably the least invasive one: http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726.v1/ It would be great if someone could verify this new version once again by running it through JPRT (I've verified that the reported problems don't occur any more, but who knows :) Thank you and best regards, Volker On Fri, Apr 14, 2017 at 3:13 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 14/04/2017 14:02, Chris Hegarty wrote: > > >> I know that Alan has provided some comments on this, but I just >> grabbed your patch and sent it through our internal build and test >> system. I observed a few failures: >> > Yes, I think URLClassLoader will be broken (Max is right, I forgot that > URLClassPath is essentially the implementation of URLClassLoader). > > I think Volker will need to change this so that > ClassLoaders.toFileURL(String) uses toFile().toURI().toURL(). That will > ensure that URLClassPath doesn't get URLs with the server name in the > authority component. > > -Alan >
