Absolute path in Manifest Class-Path header?

[bo_kid]

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

 

[Roland]

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 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).
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \

 

[bo_kid]

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

 

[bo_kid]

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

 

[John C. Bollinger]

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.

 

[Lee Fesperman]

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 ;^)

 

[John C. Bollinger]

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?

 

[Lee Fesperman]

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 ;^)

 

[bo_kid]

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

 

[John McGrath]

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.

 

[bo_kid]

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