Guilhem Lavaux wrote: > Apparently the special parseURL implementation in > gnu.java.net.protocol.file.Handler is not required anymore and even > broken according to mauve test gnu.testlet.java.net.URL.URLTest. If we > replace it using GCJ implementation (attached) 39 failures > are fixed and no regression happens. So I suggest to use it directly. > I haven't yet tested the URL "file:/d|/test.txt" on windows but on Linux > GNU Classpath and JDK gives the same result if we suppress this > implementation...
I spent almost the entire day on it, but I finally have it working :-) I hope I never have to see another URL ever again... <g> BTW, using a pipe instead of a colon doesn't work on the Sun JDK, so I don't think we need to bother with that. Attached is the patch I ended up with (this includes your patch). I think all the URL Mauve tests now pass on Windows and Eclipse 3.0 M8 continues to run (this was an extremely good test case). I'm pretty sure I didn't break non-Windows behavior, but please do take a look at the code. Here's what I did: File.toURL(): Use constructor that doesn't require parsing, to bypass problems that arise from the fact that absolute Windows paths do not start with a slash (Unix "/foo" should result in file:///foo, while on Windows "c:/foo" should result in file:///c:/foo). URL: No additional changes. URLStreamHandler.parseURL(): Added code to change File.separatorChar to / for "file" protocol. The Sun JDK does the same, URLs always use /, but when parsing they accept backslashes too. Removed code that deals with backslashes. Added code to change File.separatorChar to / after using File.getCanonicalPath to canonicalize the path (which had the unintended side effect of introducing the backslashes again). Regards, Jeroen
url.patch
Description: url.patch
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
