Absolute path in Manifest Class-Path header?

Discussion in 'Java' started by bo_kid@yahoo.com, May 18, 2005.

  1. Guest

    , May 18, 2005
    #1
    1. Advertising

  2. Roland Guest

    On 18-5-2005 11:42, wrote:

    > Is it possible to use absolute paths in the manifest Class-Path header?
    > If yes, how?
    >
    > I've already tried with:
    > Class-Path: c:\xxx.jar
    > andClass-Path: c:/xxx.jar
    >
    >
    > This is a follow up on the following thread:
    > http://groups-beta.google.com/group...cf82ab33f35/201a23e51f9a3d77#201a23e51f9a3d77
    >
    >
    > Thanks for any help,
    > /Kid
    >

    According to
    <http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Main%20Attributes>,
    the Class-Path attribute specifies relative URLs. So that would probably
    mean no.
    However, you could try to use a URL instead of a file path, e.g.
    file:///C:/Documents%20and%20Settings/foo/bar.jar (I've never tried it
    myself, though).
    --
    Regards,

    Roland de Ruiter
    ___ ___
    /__/ w_/ /__/
    / \ /_/ / \
    Roland, May 18, 2005
    #2
    1. Advertising

  3. Guest

    Of course one have to use java URLs!

    Thanks alot Roland, it works. =)

    I guess that Sun meant something different when they say relative urls,
    because it works both on windows and linux using absolute paths in
    Class-Path.

    Thanks again!
    /Kid
    , May 19, 2005
    #3
  4. Guest

    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?

    Best Regards,
    /Kid
    , May 20, 2005
    #4
  5. 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.

    --
    John Bollinger
    John C. Bollinger, May 20, 2005
    #5
  6. John C. Bollinger wrote:
    >
    > 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 ;^)

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

    > John C. Bollinger wrote:
    >
    >> 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?

    --
    John Bollinger
    John C. Bollinger, May 23, 2005
    #7
  8. John C. Bollinger wrote:
    >
    > Lee Fesperman wrote:
    >
    > > John C. Bollinger wrote:
    > >
    > >> 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)
    Lee Fesperman, May 23, 2005
    #8
  9. Guest

    To add some more questions to the discussion:

    When using an external jar by giving the absolute path to it in the
    Class-Path header, the working directory for the classes in the
    external jar is still the one for the jar package, is this correct?

    Let me explain some further:
    I have a java application which needs some external jar-files
    (openoffice). These external jar files do one tricky thing: they looks
    for some native libraries relative to their own location.
    Until now, I've run my java application by directly running the main
    class and giving the external jar files with -cp arguments:

    java -cp {absolute path to external jar} Main.class

    This works correct.
    Now I'm trying to pack the java application into a jar file, MyApp.jar,
    so it's easier to handle.
    I can't run it with:

    java -cp {absolute path to external jar} -jar MyApp.jar

    because the -cp has no affect when using -jar.
    Therefore I have to use the Class-Path header.
    When using the header correctly:

    Class-Path: {absolute path to external jar with file:/// protocol}

    The external jar-files are found and the classes are loaded, BUT when
    they try to locate the native libraries they fail! It seems that they
    can't create an absolute path the the library.

    Is this behavior correct?

    Best Regards,
    /Kid
    , May 24, 2005
    #9
  10. John McGrath Guest

    On 5/24/2005 at 4:38:08 AM, wrote:

    > When using an external jar by giving the absolute path to it in the
    > Class-Path header, the working directory for the classes in the
    > external jar is still the one for the jar package, is this correct?


    The working directory is controlled by the host operating system and is
    not affected by the classpath. Generally, it will be the working
    directory that was in effect when you launched the JVM.

    > I have a java application which needs some external jar-files
    > (openoffice). These external jar files do one tricky thing: they looks
    > for some native libraries relative to their own location.


    > The external jar-files are found and the classes are loaded, BUT when
    > they try to locate the native libraries they fail! It seems that they
    > can't create an absolute path the the library.
    >
    > Is this behavior correct?


    The OpenOffice.org code is determining the location of the native
    libraries on its own, and it sounds like that is where the problem is.
    Whether or not it is the *correct* behavior really on the design
    specifications and documentation for OpenOffice.

    In any case, it looks like the algorithm used in OpenOffice to find the
    native libraries is lacking. My guess is that it is using the classpath
    (either the "java.class.path" System property or the URL list from the
    AppClassLoader) to determine the directories to look in. However, paths
    listed in the JAR manifest "Class-Path" attribute would not be included
    in either.

    I think a better approach for OpenOffice to use would be to get the path
    from one of the classes in the OpenOffice JAR file. This can be done with
    the following expression:

    XXX.class.getProtectionDomain().getCodeSource().getLocation();

    The above methods can return null, so the code would need to check the
    return values before referencing them, but that is pretty much what would
    be needed.

    Depending on how the OpenOffice code is written, it may also be using the
    default mechanism for locating libraries, System.loadLibrary(). If that
    is the case, then the default search path would be the value of the System
    property "java.library.path". You might try setting this to point to the
    directory that contains the native libraries. Note that you cannot do
    this programmatically, since the value will be processed by the JVM setup
    code. You need to specify this on the Java launcher command line.

    --
    Regards,

    John McGrath
    John McGrath, May 26, 2005
    #10
  11. Guest

    Thanks for the great information John!
    I should maybe take a peak at the java source for OpenOffice and see
    how it's done.

    Thanks again!
    /Kid
    , May 30, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tom Davies

    manifest.mf Class-Path:

    Tom Davies, Jul 15, 2003, in forum: Java
    Replies:
    1
    Views:
    897
    Dave Glasser
    Jul 15, 2003
  2. Karsten Wutzke

    JAR files and manifest: Class-Path

    Karsten Wutzke, Jan 6, 2004, in forum: Java
    Replies:
    6
    Views:
    78,222
  3. hiwa
    Replies:
    3
    Views:
    8,434
    John C. Bollinger
    Jan 15, 2004
  4. Replies:
    1
    Views:
    2,356
  5. James Byrne
    Replies:
    3
    Views:
    556
    James Byrne
    Sep 14, 2010
Loading...

Share This Page