-
Bug
-
Resolution: Unresolved
-
P4
-
8, 11, 13, 15, 16
Internally in the javax.print API we have some cases where
we are using "file:out.prn" as the string with which to initialise
a URI to create an instance of Destination.
The intent is for this to be interpreted as relative to the CWD,
and that requesting the path from a URI would return "out.prn"
to be passed to a File constructor.
But URI.getPath() will return null because it is considered opaque since it doesn't start with /
Ideally you would be able to use new File(URI) but that fails
with
> java.lang.IllegalArgumentException: URI is not hierarchical
for such URIs
We have "fixed" some cases where that was seen to use
URI.getSchemeSpecificPart() to extract what we need but
there is a location in ServiceDialog that was overlooked
and can still generate such an error which is caught and
so manifests only as substituting a different default file
in the dialog.
We probably should do the same to be more resilient ( but
should we also think about whether we should be using
"file:out.prn" in our code ? )
That is issue #1
Issue #2 is that we intend the file to be relative to the CWD
but when the Swing JFileChooser is brought up to confirm
the choice, it will present the file relative to the user's home
directory, since that is the default for this component.
We need to set it to CWD first.
If the file is absolute everything is fine.
we are using "file:out.prn" as the string with which to initialise
a URI to create an instance of Destination.
The intent is for this to be interpreted as relative to the CWD,
and that requesting the path from a URI would return "out.prn"
to be passed to a File constructor.
But URI.getPath() will return null because it is considered opaque since it doesn't start with /
Ideally you would be able to use new File(URI) but that fails
with
> java.lang.IllegalArgumentException: URI is not hierarchical
for such URIs
We have "fixed" some cases where that was seen to use
URI.getSchemeSpecificPart() to extract what we need but
there is a location in ServiceDialog that was overlooked
and can still generate such an error which is caught and
so manifests only as substituting a different default file
in the dialog.
We probably should do the same to be more resilient ( but
should we also think about whether we should be using
"file:out.prn" in our code ? )
That is issue #1
Issue #2 is that we intend the file to be relative to the CWD
but when the Swing JFileChooser is brought up to confirm
the choice, it will present the file relative to the user's home
directory, since that is the default for this component.
We need to set it to CWD first.
If the file is absolute everything is fine.