Absolute path in Manifest Class-Path header?

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

  1. bo_kid

    bo_kid Guest

    bo_kid, May 18, 2005
    1. Advertisements

  2. bo_kid

    Roland Guest

    According to
    <http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Main Attributes>,
    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).

    Roland de Ruiter
    ___ ___
    /__/ w_/ /__/
    / \ /_/ / \
    Roland, May 18, 2005
    1. Advertisements

  3. bo_kid

    bo_kid 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

    Thanks again!
    bo_kid, May 19, 2005
  4. bo_kid

    bo_kid Guest

    Thanks for your mail Vitaly Shelest.

    works and seems to have the same effect as

    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

    Best Regards,
    bo_kid, May 20, 2005
  5. 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 C. Bollinger, May 20, 2005
  6. 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, May 20, 2005
  7. 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 C. Bollinger, May 23, 2005
  8. 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, May 23, 2005
  9. bo_kid

    bo_kid 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,
    bo_kid, May 24, 2005
  10. bo_kid

    John McGrath Guest

    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.
    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:


    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.
    John McGrath, May 26, 2005
  11. bo_kid

    bo_kid 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!
    bo_kid, May 30, 2005
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.