There need to be APIs, probably on java.io.File, to facilitate an easy
"round-trip" conversion from a platform file path name to a URI object
representing that path name (ie a "file:" scheme URI) and back to the
original platform file path name. This lossless round trip conversion
presumes the same platform used throughout.
This is not as easy as pre-fixing the pathname with "file:" as the
new URI class in 1.4 faithfully implements RFC2396, which treats
the "\" as an "unwise" character, so in general there are restrictions on
what characters may be in a URI.
Currently (up to and including b67) bug 4464135 in URI actually allows a URI
to be constructed containing a "\".
Once that bug is fixed it may become difficult or impossible to represent
all file: URIs without at the very least specific knowledge of the pathname
conventions of the executing platform and the restrictions of URI and
JDK support for encoding and decoding the URIs.
This will be a particular problem for the new printing APIs which
were updated to adopt the new URI class and require developers to
use URIs which contain file: scheme URIs.
Developers need a simple way of doing this, such as the following:
APIs on File such as
/**
* @return : a file: scheme URI which represents this file object's
* platform path name.
*/
public URI toURI()
and
/**
* @param a uri representing a file: URI
* @return a File object for this URI
* @throws URISyntaxException if the uri parameter does not represent
* a valid path URI for this platform.
*/
public static getFile(URI uri) throws URISyntaxException
"round-trip" conversion from a platform file path name to a URI object
representing that path name (ie a "file:" scheme URI) and back to the
original platform file path name. This lossless round trip conversion
presumes the same platform used throughout.
This is not as easy as pre-fixing the pathname with "file:" as the
new URI class in 1.4 faithfully implements RFC2396, which treats
the "\" as an "unwise" character, so in general there are restrictions on
what characters may be in a URI.
Currently (up to and including b67) bug 4464135 in URI actually allows a URI
to be constructed containing a "\".
Once that bug is fixed it may become difficult or impossible to represent
all file: URIs without at the very least specific knowledge of the pathname
conventions of the executing platform and the restrictions of URI and
JDK support for encoding and decoding the URIs.
This will be a particular problem for the new printing APIs which
were updated to adopt the new URI class and require developers to
use URIs which contain file: scheme URIs.
Developers need a simple way of doing this, such as the following:
APIs on File such as
/**
* @return : a file: scheme URI which represents this file object's
* platform path name.
*/
public URI toURI()
and
/**
* @param a uri representing a file: URI
* @return a File object for this URI
* @throws URISyntaxException if the uri parameter does not represent
* a valid path URI for this platform.
*/
public static getFile(URI uri) throws URISyntaxException
- relates to
-
JDK-4463790 Print to file using cross-platform printDialog does not work.
-
- Resolved
-