Re: File.toUrl, is this a bug? the problem

["Ranjit Mathew" <rmathew4lists at hotmail dot com>]

> sorry I did not mentioned that earlyer. The File.toURL() and
> URL.getFile() return the same results as in the sun jvm. I tested that
> already. If compliancy is wanted then the changes could be done in the

To summarise:

    'new File( "c:\\temp\\foo.txt").toURL( )' returns 
    the URL object for "file:/c:/temp/foo.txt"

    This URL's getFile( ) returns "/c:/temp/foo.txt".

    'new File( "/c:/temp/foo.txt").toString( )' gives
    "c:\temp\t.txt" with Sun's JRE but gives "\c:\temp\t.txt"
    with GCJ, which causes problems later.

Some time back, I had submitted a patch for fixing more of
filenames handling code on GCJ for Win32:

    http://gcc.gnu.org/ml/java-patches/2003-q1/msg00636.html

but admittedly that still does not handle this case. :-(
(The patch has not been reviewed yet.)

The problem is that going strictly by the JDK API docs, I
do not think the path "/c:/temp/t.txt" is valid but apparently
it does seem to work with Sun's JRE. (Even File.isAbsolute( )
returns true with this path with Sun's JRE, though it should not, 
going strictly by the docs...)

~uggghhh~ I guess we will have to fix this special case. I
wonder how many other special cases we will have to handle
before we can claim 100% compliance with the reference
implementation...


> FileInputStream.java class. (In the sun jvm there is a
> FileSystem.normalize method called) maybe something similar is needed.

Interesting. There's this public (abstract) class java.io.FileSystem
but it is not documented by the main JDK API docs, though I could
find documentation for it, for example, here:

    http://www.erights.org/javadoc/java/io/FileSystem.html

Can anyone shed any light on this? libgcj does not have this
class and its concrete implementations - should we have it?

Ranjit.