[9] RFR(S): 8178726: Can't load classes from classpath if it is a UNC share

[Volker Simonis]

On Wed, Apr 19, 2017 at 9:03 AM, Alan Bateman <Alan.Bateman at 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