On Fri, 4 Jun 2004, Norman Gray wrote:
> Peter and Mark,
>
> On 2004 Jun 4 , at 11.27, Peter W. Draper wrote:
>
> > On Fri, 4 Jun 2004, Mark Taylor wrote:
> >>>
> >>> C:\Program Files\STARJAVA\lib\treeview>java -jar treeview.jar
> >>> java.lang.AssertionError: Failed to convert URL <file:/C:/Program
> >>> Files/STARJAVA
> >>> /etc/treeview/demo/ndx/rdata2.sdf#DATA_ARRAY> to URI
> >>> at uk.ac.starlink.util.URLUtils.urlToUri(URLUtils.java:166)
> >>
> >> OK there is clearly some problem with URLUtils.urlToUri(), no doubt
> >> to do with forward and backslashes or drive letters - the comments
> >> (not sure if they're Norman's or mine) in that method suggest there's
> >> probably something to get confused about in any case.
> >
> > actually the space in "Program Files" may be the problem.
>
> There should be no spaces in URIs, so I think the problem here is that
> urlToUri is being asked to convert an illegal URL and objecting. So
> _that's_ how this can fail! I think they're my comments, and I should
> tidy them up, with this explanation, and a more suitable exception.
>
> Also, I'm pretty positive that a colon is an illegal character in URLs.
> I've seen this sort of thing as <file:/C|/Program...>, I think, but I
> can't see this documented anywhere obvious within java.net.URL. How is
> this problematic URL being constructed? If it's not being done using
> the multi-argument constructors of java.net.URL, it probably should be,
> since I imagine they use java.net.URLEncoder internally. That doesn't
> say anything about windows drive letters, but it would have escaped the
> colon.
>
> Hmm. A bit of googling leads me to
> <http://www.erights.org/elang/io/uri-exprs.html> which incidentally
> mentions URLs of the form file:drive:path, which clearly therefore work
> on at least some platforms. Of course, that doesn't mean it's right.
> I'll check the
> RFC later.
Norman,
Java seems to be constructed to work as if this is all OK (regardless of
what the RFC might say), you can see this from just looking at the URLs
used to access local resources. However, as you say the problem is almost
certainly down to the spaces not being escaped properly (whose job that
is/was I don't know).
> > Only problem with that
> > idea is that I'm sure this all used to be OK, and no one seems to have
> > modified NDX/HDX/URLUtils in any ways that would affect this.
>
> Can this be another Java version problem?
Indeed it is, switching back to 1.4.1_02 from 1.4.2_04 cures the original
problem and Treeview displays NDXs in "Program Files" again. At this late
stage I'd suggest we recommend this JRE version (same as last time around)
and make a note that later versions don't work (with NDX formats) when
there are spaces in the names.
As for the future, I've tried to run the JUnit tests under Windows and
there are problems with the URL handling in HDX, NDX, HDS, FITS and TABLE.
Before blaming Java I'd suggest we try to resolve these known problems.
Since I'm already working at this I'll spend the rest of the afternoon
having a further look-see.
Peter.
|