Re: Patch: URLClassLoader change

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Mon, 2002-12-30 at 23:37, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:
> 
> Mark> Yes, the patch will fix that and give file:./BadURL.java.
> 
> I'd prefer we get an absolute path if possible.

Me too. But this is code shared with Classpath, not all URL and File
handling classes have been merged yet. And there are people that use
Windows based file systems that behave in ways I don't really (want to)
understand. 

> I did some debugging of this.
> 
> I don't understand why URLClassLoader.FileResource.getURL uses the
> constructor it uses.  In this code we already know that `file' has the
> full path.  Why not:
> 
>     new URL("file", "", -1, file.toString(),
>             loader.classloader.getURLStreamHandler("file"));
> 
> This seemed to work for me, but perhaps I'm missing something.  Maybe
> the separators are incorrect on Windows?  What do you think of this?

It seems to me that it would break on Windows since file URLs use
forward slashes, but file.toString() will give a path with backward
slashes. (And I remember that MacOS based file systems use : as
separator)

One of the problems is that I don't know for sure how/when the given
URLStreamHandlerFactory is used. Some documentation seems to suggest
that it is only used when constructing jar URLs, but in other places it
says that the given StreamHandler is used to construct URLs when needed.
If it is the case that it is only needed for constructing jar URLs then
maybe we could just use File.toURL() at this point (and hope that does
the correct thing in both Classpath and gcj on Posix and Windows based
systems.

Jeroen: Could you check that File.toURL() does the correct thing with
IKVM.NET?

Cheers,

Mark