Jeff Verdegan wrote:
Again, this has nothing to do with Java.
I disagree. S/He's trying to run a java program, and one has to understand how the classes are found (and not found) to do that. It is a place where the shell and the java environment have to cooperate a little, and the explanations I've seen for it are confusing. Too many examples, not enough explanation of principle.
I am short of time this evening, so I am just going to get down a few principles that
you should know and point you to some things you might be able to look up yourself. I do not know if I will get back in a few hours to solve the specific problem or not, but I think this is more important.
The directory path to a java class is determined by its package; you can put class files on a disk in a directory structure and run them from there IF your JVM has the root directory of that structure on its classpath.
So if you're running a class in a package named com.iona.math, and the class is named Matrix, then you can put Matrix.class into a directory named math in a directory named iona in a directory named com (on Windows, com\iona\math\Matrix.class). The next question is, where does com need to go?
Often the 'current directory', a concept common to most environments, is on the classpath; if your current directory is c:\test\, and com is in that directory, and "." (the symbol for the current directory) is in the class path, then you can run your program and it can import and use Matrix.
If you have a jar file, then realize that a jar file is a specific kind of zip file, and zip files store directory structures as well as file names. So if you create your jar to have relative paths so that Matrix is in com/iona/math within the jar file (and you have remembered to NOT store it with the full path in front of com), then the classpath can contain the jar file and your program will have access to Matrix.
Note that, if you specify the jar file as a relative name, then your current directory will have to be in the right relative position; if you are, again, in c:\test\, and you want to say "java -jar MathStuff.jar", then MathStuff.jar has to be in the current directory. If you say java -jar x\MathStuff.jar, then it has to be in x in
test, and you can also say c:\x\MathStuff.jar so it won't matter what your current directory is.
Now, once you understand all that, you can look up manifest files. A manifest.mf file is a special file you can put in a jar to help the JVM decide how to run it. One of the things you specify in a manifest file is the main class for the program, i.e., the class containing 'main(
String[] args)'. You can package your stuff in a jar, including a manifest in the root of the jar, and (on windows at least) double-click on the jar to run it. If you have other libraries you need, there is a way to specify THEM in the jar, by specifying a classpath in the jar.
Eclipse will create such a jar for you; the options for it are a bit tortuous, even for one familiar with it, but once you get it created it's very easy to create it again.
I will try to get back to this in 3-4 hours to see if we can solve the specific problem, but these are the principles to start with, and you should read up on manifest files if you don't know them already. I can say that, when you changed the location of the batch file, you probably then changed your current directory down to EOD, and the command line phrase "-jar RR_Jar\NOPARAM_PDF.jar" can't find that jar because it is looking for RR_Jar relative to its current directory, which no longer contains RR_Jar.
Will try to get back tonight.
rc