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
