RE: gnu.java.net.protocol.file.Handler update

[Jeroen Frijters]

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