So I have two file disks (I think that's the right terminology):
C:
D:
I'm running a Windows 7 and it is installed on the C: drive. There is a jar file in D:\path\to\jar that I want to run. The problem, though, is that when I run the following command:
java -jar D:\path\to\jar\myJar.jar
I get an error from the program within myJAR.jar that some other jar file could not be found (let's call this jar file theirJar.jar). But in the MANIFEST file of myJar.jar, theirJar.jar is included in the class path.
What's the manifest for the classpath for the jar? Is it an absolute path (offhand I'm thinking that this *has* to be relative, but can't recall if the jar will build on an absolute)?
It looks like it simply can't find it which would be the case if the classpath isn't absolute (which I'm thinking it can't be) and the actual CLASSPATH doesn't include the path to this linked jar. If it looks good, I'd try moving your jar to anywhere on C that is not the original location (if it existed), and is not in a system path and see if that goes. If that goes, its possible that this is a security issue across the volumes.
Yes the classpath for that jar is relative. It's weird, though.
If I change to class path of the included jar to an absolute path to that included jar (D:\path\to\jar\theirJar.jar) it then get the error that a class from myJar.jar (the main class) cannot be found. If I don't place the absolute path, it is found but fails at running because theirJar.jar cannot be found.
I currently want that jar in the D: drive. Plus I want to solve the error instead of doing something to avoid it.
Yeah, I kinda figured it had to be relative.
I'm not suggesting that you don't fix it, but determine what the problem is first. Moving it to C somewhere and running it will verify whether it is a security issue or if it is a path issue. I'd suspect a path issue nonetheless now that you verified that the manifest has to be relative.
So, there are two ways to fix this. First, you can add a bootstrap path to load the jar first using -Xbootclasspath/a:/path/to/ur/resource.jar, and the other is to move the external jar (what I would recommend). Grab your external jar and throw it in your jdk's lib\ext directory. Not sure where you'll find it, but it'll be along the lines of C:\Program Files\Java\jre6\lib\ext for example. Once there, that should run no problem with a manifest of just Class-Path: yourexternal.jar
BUT both solutions do not seem to work; for the second solution I moved the resource jar into the ext folder but it still could not be found when I ran: java -jar D:\path\to\jar\myJar.jar
And when I added the bootstrap path, it also gave the same error: java -Xbootclasspath/a:D:\path\to\jar\theirJar.jar -jar D:\path\to\jar\myJar.jar java -Xbootclasspath/a:"D:\path\to\jar\theirJar.jar" -jar D:\path\to\jar\myJar.jar
BUT both solutions do not seem to work; for the second solution I moved the resource jar into the ext folder but it still could not be found when I ran: java -jar D:\path\to\jar\myJar.jar
And when I added the bootstrap path, it also gave the same error: java -Xbootclasspath/a:\path\to\jar\theirJar.jar -jar D:\path\to\jar\myJar.jar java -Xbootclasspath/a:"D:\path\to\jar\theirJar.jar" -jar D:\path\to\jar\myJar.jar
This should be right. The classpath with only the jar name should be usable from any known CLASSPATH location such as the lib\ext of the running version.
Execute java.exe using the full path to the bin that shares the version with where you dropped the lib\ext. See if its your java.exe thats in Windows\system32 that's causing that issue.
Edit:
BTW, what is the actual stack trace you are getting? I assumed a classloader issue with the end result of a NoClassDefFound error.
Well, there isn't really a stack trace (as myJar.jar is really the producer's jar, and theirJar.jar is a library he includes). It just says that theirJar.jar could not be found.
A solution I have found was to:
D:
cd path\to\jar
java -jar myJar.jar
But I don't know why this works and the other solutions do not.
There should still be a stack trace though. Let me pull an example of a bad run off my test:
Code:
Exception in thread "main" java.lang.NoClassDefFoundError: gui/Frametest
at test.main(test.java:10)
Caused by: java.lang.ClassNotFoundException: gui.Frametest
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 1 more
So this is what I get when I can't find the class Frametest. I ran this against a U: and pulled my Frametest.jar (name is irrelevant actually) from the C:\Program Files\Java\jre6\lib\ext directory.
This is why I'm curious if you may have a different version of the java.exe in system32 (or, perhaps a version applied to the path itself?).
The error displayed didn't have a stack trace. I downloaded the source of the program and tried to locate the error. It seems to be something related to: if(! (new File("theirJar.jar")).canRead()) { - so I'm guessing File() is treating my "current" directory as the directory to work with, but it should really be working in the directory the jar belongs to. How would I do this?
Oooohhhhh I see, so this isn't actually called via import commands, you are using something like the classloader itself.
Is this your check (given the file name I'd suspect yes)? If it is, simply remove the check and use a try/catch instead. You don't care if the jar exists at all, you only care if the class itself is available whether it be through a jar or through a .class.
Before you post, read our: 
:\path\to\jar\theirJar.jar -jar D:\path\to\jar\myJar.jar
