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

[Alan Bateman]

On 13/04/2017 19:50, Volker Simonis wrote:

> Hi,
>
> can you please review the following change which fixes a problem with
> UNC paths on the Windows class path:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726/
> https://bugs.openjdk.java.net/browse/JDK-8178726
>
> I would appreciate if somebody could run this trough JPRT for me. I
> won't be available until Tuesday after Easter so there's some time for
> testing :)
Yes, this is a regression, it seems specific to a class path with 
exploded classes on a network share. The issue has been there since 
jdk-9+111 but I don't think has been reported before now.

I can do some testing with your patch. My general concern is that there 
are lot of conversions going on, specifically URL -> URI -> Path -> File 
(this is after the initial setup that amounts to String -> Path -> URI 
-> URL). I think URLClassPath (which dates back to JDK 1.2 I think) is 
crying out to be replaced and we probably should have done a long time 
ago. Too late now as we have to be cautious.

Given that `dir` is only needed when the resource name contains a ".." 
then there shouldn't be any need to initialize it in the constructor, it 
can be lazy. That would reduce the risk with changing this fragile area. 
It would also remove some of the overhead with a really long class path. 
Once JDK 9 is out of the way then I think we should replace 
URLClassPath.FileLoader, if not all of URLClassPath.

-Alan