On Wed, Apr 19, 2017 at 9:03 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 18/04/2017 18:44, Volker Simonis wrote: > > 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 :) > > I ran it through the build+test system and don't see any issues. It's great > that you found this issue before GA, I suspect testing with a directory of > .class files on a UNC isn't too common (for performance reasons) which is > why it wasn't noticed (the issue has been in JDK 9 for more than a year). > > One additional suggestion is to include a comment, something like: > > // use File::toURL as URLClassPath can't handle URLs with a UNC > // server name in the authority component > > as it won't be immediately clear to readers why the toFile() is needed in > the chain.
That's a good suggestion. I've updated the patch with a slightly modified comment: // Use an intermediate File object to construct a URI/URL without // authority component as URLClassPath can't handle URLs with a UNC // server name in the authority component. and also updated the copyright year: http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726.v2/ Can you please add a "jdk9-fix-yes" label to the bug such that I can push the change? Thanks, Volker > > -Alan
