File.toUrl, is this a bug? the problem

Tue Apr 15 08:59:00 GMT 2003

> 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. 