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

[Weijun Wang]

I see some changes:

- relative url won't be supported

- path is no longer canonicalized

Maybe these are no problem for URLClassPath. Just my 2 cents.

--Max

On 04/14/2017 04:41 PM, Alan Bateman wrote:
> 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