Re: Absolute path in Manifest Class-Path header?

John C. Bollinger wrote:
>
> Lee Fesperman wrote:
>
> > John C. Bollinger wrote:
> >
> >>bo_kid@xxxxxxxxx wrote:
> >>
> >>
> >>>Thanks for your mail Vitaly Shelest.
> >>>
> >>>/c:/ext.jar
> >>>works and seems to have the same effect as
> >>>file:///c:/ext.jar
> >>>
> >>>I'm really curious about this. Where can one find information about
> >>>this? Did you just use try and error or is this /c:/... documented
> >>>somewhere?
> >>
> >>I STRONGLY suspect that this is an implementation quirk, not a supported
> >>behavior. The string you describe is not a well-formed pathname on
> >>Windows, and I have never seen mention of this behavior among the
> >>specifications and docs. I can, however, imagine implementation code
> >>that happened to make this work by accident. If my characterization is
> >>correct, then it is not safe to assume that this will continue to work
> >>in future versions of the Java tools.
> >
> >
> > Check the javadocs for java.net.URL. The leading slash (/) is used to
> > prevent "c:" being parsed as a protocol specification. If the default
> > protocol is set to "file:" (a reasonable assumption in this case), such
> > a string would be parsed as an 'absolute' file path. This is just a guess
> > on my part, but it does fit. We use this 'trick' in our software; it does
> > work ... with some odd variations between JDK versions ;^)
>
> Ah. So you're saying that "/c:/ext.jar" is interpreted as a URL instead
> of as an absolute path? It still sounds like there is more undocumented
> behavior involved than I would be comfortable relying upon. If it is
> meant to be a URL, then putting "file://" in front of it removes all
> ambiguity for small cost. Do you happen to know whether the same
> variations between JDK versions also affected that form?

The docs do say that URLs are being used. What they don't seem to mention is the default
protocol is "file:". In our software, we are explicit about this in the docs.

As to variations, I did a quick check on 1.1, 1.2, 1.3 and 1.4 using java.net.URL. The
differences are quite complex, but, in general, the parsing becomes more liberal about
'relative' paths in later versions. For instance, JDK 1.1 apparently doesn't allow
relative paths at all. 1.1 seems to assume they are all absolute. After 1.1, earlier
versions allow relative paths with "drive:" specifications if it is the current drive.
By 1.4, any drive can referenced. As far as I checked, "file://" must be absolute and
the slash is required after "drive:", but "file:/d:" can be relative. Rather messy ;^)

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
.

Relevant Pages

  • Re: System.getProperty("user.dir") cannot rerturn the package directory.
    ... John C. Bollinger wrote: ... > live on a filesystem. ... > John Bollinger ...
    (comp.lang.java.programmer)
  • Re: Global Servlet Filter
    ... John C. Bollinger wrote: ... >> I'm writing a servlet filter that will keep track of the number of ... > correctly would be container-dependent. ... > John Bollinger ...
    (comp.lang.java.programmer)
  • Re: Java tools
    ... > John C. Bollinger wrote: ... IDEs do not tend to get in the way of learning such ... > paper and have students write a bunch of zeroes and ones. ...
    (comp.lang.java.programmer)
  • Re: Can I redirect STDIN to a socket?
    ... John C. Bollinger wrote: ... > John Bollinger ... The source VM just needs to reroute its STDIN (through socket). ... server VM processes the stream, then responds to the source VM)through ...
    (comp.lang.java.programmer)
  • Re: Need help w. getOutputStream( )
    ... John C. Bollinger wrote: ... > need to post the code and the actual text of any error messages to get ... > John Bollinger ... Hi John, this is steve Burrus, and here is the requested servlet code ...
    (comp.lang.java.programmer)