On win32, C:\path is valid, while \C:\path is not. Under VxWorks,
<hostname>:/path is valid, while /<hostname>:/path is not. But because
of the fact that File.toURL() always prepends a slash if there isn't one,
and FileURLConnection does not remove the slash (so the transformation
from path to URL and back to path is lossy and non-reversible), the
burden of undoing the slash is left to FileSystem.normalize(), which
means that \C:\path, an invalid path, is (and must be) recognized. If it
were not recognized, then classloading would not work because
sun.misc.Launcher insists on using URLs instead of simple path strings.

It would be nice if a pathname could be converted to a file: URL and
back to a pathname in a completely reversible. But short of that,
then it should be documented that FileSystem.normalize() explicitly
must deal with leading slashes in order to support file: URLs.

dean.long@Eng 1999-11-06

In addition to FileSystem.normalize(), sysNativePath() in the HPI
porting layer is also required to strip off a leading file
separator. This shows up, for example, because URLClassPath
creates a JarFile using the pre-normalized path from the URL.
Luckily, ZIP_Open calls sysNativePath() which saves the day.

dean.long@Eng 1999-11-07