If I am creating superjar.jar and it needs a jar file stellar.jar I need to add the following line to the manifest file for superjar.jar
Class-Path: path/to/stellar.jar. But in my classpath I already have stellar.jar. So whats the deal here? Why can't superjar.jar attempt to look up the location of stellar.jar from my classpath?
I need to add the following line to the manifest file for superjar.jar Class-Path: path/to/stellar.jar.
You need that path in your superjar, if the environment variable CLASSPATH is ignored, and it is ignored, if you use the superjar as executable jar, and start it with
java -jar superjar.jar
superjar.jar can access the classpath, if it is started without overriding the classpath with an different ad hoc classpath, and without the technik of running an executable jar, which always just uses the CLASSPATH inside that jar, and always ignores additional attempts of classpaths.
CLASSPATH=/foo/bar/superjar.jar:/opt/some/stellar.jar
java somepackage.SomeClass
Wether the classpath is relative or absolute is a different, unrelated discussion. Above example uses Unix/Linux-Syntax. On Windows you would use backslashes and as delimiter ";".
If CLASSPATH means an environment variable, then you're about to learn that Java, all IDEs, and all Java EE app servers ignore it.
I don't have CLASSPATH environment variable on any machine that I work on, because it's useless. You need to learn how to set CLASSPATH properly without depending on an environment variable.
Two things:
The path to stellar.jar is relative to superjar.jar
If stellar.jar is already in the classpath, it is in the classpath irrespective of what superjar.jar's manifest says.
Related
I'm trying to get my application classpath.
I have a jar (named application.jar) and it have in its Manifest.mf other jar files, like Class-Path: a.jar b.jar.
Why when I use System.getProperty("java.class.path") my jars a.jar and b.jar are not listed?
It possibly has to do with the fact that the java.class.path is a system property that is set from the classpath environment variable ($CLASSPATH or -classpath). These are ignored with the -jar option is used.
As per the java -jar documentation, when that jar option is used to run an application, only the manifest Class-Path is considered and other settings are ignored.
From http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/java.html:
-jar
Execute a program encapsulated in a JAR file. The first argument is the name of a JAR file instead of a startup class name. In order for this option to work, the manifest of the JAR file must contain a line of the form Main-Class: classname. Here, classname identifies the class having the public static void main(String[] args) method that serves as your application's starting point. See the Jar tool reference page and the Jar trail of the Java Tutorial for information about working with Jar files and Jar-file manifests.
When you use this option, the JAR file is the source of all user classes, and other user class path settings are ignored.
That's excactly the question I came along as well. Even if when using java -cp ..;myTest.jar test2.Needer I get only "..;myTest.jar" as a result for java.class.path property.
Note: Even when using the -cp parameter the given class-path in the MANIFEST.MF is searched! (Couldn't find this information on google and tested myself)
So i don't think that is has something to do with the -jar parameter. In Link you can find
Expansion of wildcards is done early, prior to the invocation of a program's main method, rather than late, during the class-loading process itself.
Interestingly i found out during my tests: The classpath in MANFIFEST.MF is searched recursivly. So if there is an given test.jar File in the classpath in MANIFEST.MF of myTest.jar, the class-path in the MANIFEST.MF of the test.jar will be looked up as well (when using java -cp "myTest.jar" test2.Needer).
As a result, when the java.class.path property would support showing the the classpath of the MANIFEST.MF, it should also show the classpathes of all subsequently depending .jar files. Since the classpath is only searched until classes are found, this wouldn t refer nicely to the lazy loading mechanism.
TL;DR: I think that this has nothing to do with the -jar Parameter (-cp is concerned as well). In my explanation, the support for showing the classpath from the MANIFEST.MF would only come with additional, senseless recursive search costs (because there needn't to be an actual dependency, respectivly what is used from the .jar). And since this sensless search would delay the program start (since the recursive search could be really deep), it is not implemented.
What is the difference between running a Java application withjava -cp CLASSPATH and java -jar JAR_FILE_PATH? Is one of them preferred to the other for running a Java application? I mean which one of these ways is more expensive for JVM (according to their machine resources usage)?
Which one will cause JVM to spawn more threads while trying to run the application?
I prefer the first version to start a java application just because it has less pitfalls ("welcome to classpath hell"). The second one requires an executable jar file and the classpath for that application has to be defined inside the jar's manifest (all other classpath declaration will be silently ignored...). So with the second version you'd have to look into the jar, read the manifest and try to find out if the classpath entries are valid from where the jar is stored... That's avoidable.
I don't expect any performance advantages or disadvantages for either version. It's just telling the jvm which class to use for the main thread and where it can find the libraries.
With the -cp argument you provide the classpath i.e. path(s) to additional classes or libraries that your program may require when being compiled or run. With -jar you specify the executable JAR file that you want to run.
You can't specify them both. If you try to run java -cp folder/myexternallibrary.jar -jar myprogram.jar then it won't really work. The classpath for that JAR should be specified in its Manifest, not as a -cp argument.
You can find more about this here and here.
PS: -cp and -classpath are synonyms.
When using java -cp you are required to provide fully qualified main class name, e.g.
java -cp com.mycompany.MyMain
When using java -jar myjar.jar your jar file must provide the information about main class via manifest.mf contained into the jar file in folder META-INF:
Main-Class: com.mycompany.MyMain
java -cp CLASSPATH is necesssary if you wish to specify all code in the classpath. This is useful for debugging code.
The jarred executable format: java -jar JarFile can be used if you wish to start the app with a single short command. You can specify additional dependent jar files in your MANIFEST using space separated jars in a Class-Path entry, e.g.:
Class-Path: mysql.jar infobus.jar acme/beans.jar
Both are comparable in terms of performance.
Like already said, the -cp is just for telling the jvm in the command line which class to use for the main thread and where it can find the libraries (define classpath). In -jar it expects the class-path and main-class to be defined in the jar file manifest. So other is for defining things in command line while other finding them inside the jar manifest. There is no difference in performance. You can't use them at the same time, -jar will override the -cp.
Though even if you use -cp, it will still check the manifest file. So you can define some of the class-paths in the manifest and some in the command line. This is particularly useful when you have a dependency on some 3rd party jar, which you might not provide with your build or don't want to provide (expecting it to be found already in the system where it's to be installed for example). So you can use it to provide external jars. It's location may vary between systems or it may even have a different version on different system (but having the same interfaces). This way you can build the app with other version and add the actual 3rd party dependency to class-path on the command line when running it on different systems.
There won't be any difference in terms of performance.
Using java - cp we can specify the required classes and jar's in the classpath for running a java class file.
If it is a executable jar file . When java -jar command is used, jvm finds the class that it needs to run from /META-INF/MANIFEST.MF file inside the jar file.
I have tried to write a program where i want to access class in a jar.
I am using netbeans as ide,Windows 7 os and have added jar in the libraries.
But i keep getting the error.
Exception in thread “main” java.lang.NoClassDefFoundError:after setting PATh and CLASSPATH
I have set the PATh variable to my <jdk directory>/bin;
CLASSPATH to %CLASSPATH%;
and JAVA_HOME to <jdk directory>
<jdk directory> =C:\Program Files\Java\jdk1.7.2
You've just learned an important lesson: Java ignores CLASSPATH environment variable.
You need the PATH to your JAVA/bin for your own convenience, but the CLASSPATH is not useful. I don't have one on any machine I work with.
You can see why: they're so idiosyncratic and specific to a given project.
You should learn how to set it using -cp option on javac.exe and java.exe. You can use Ant to build for more complex projects. And if you deploy to a Java EE app server, you need to understand the classloader hierarchy.
If you insist on using NetBeans, I'd recommend looking in the help to see how it wants you to set CLASSPATH.
You should have the jar file in your classpath to access the classes inside it. Moreover when you run a program from an IDE it overrides any classpath settings you do at system level. Please check your build path in the IDE.
I have an application contained in A.JAR. This jar has several dependencies so they are specified in the manifest as "lib/B.JAR lib/C.JAR lib/D.JAR". I have my installation directory with A.JAR, and under it I have the lib directory with the three others.
I go to my installation directory and run "java -jar A.JAR" to run the application, and it starts running. However, it looks for log4j.properties for setting up log4j. Now as far as I know, log4j.properties needs to be in the classpath.
Now let's suppose I want to run several instances of A.JAR, but with various log4j properties. So I setup 4 installation directories (inst1, inst2,...) and I've put A.JAR, a customized log4j.properties and the lib directory in each of them.
Is this the right way to go (forget about the copying itself, I can do this with symlinks)? Maybe there's a way for telling log4j to look for the properties in a specific place using some define (-D) in runtime?
If what I've described is a good setup, how can I actually run it? Java doesn't "catch" the log4j.properties as part of its classpath. running "java -classpath . -jar A.JAR" wasn't helpful as well.
You can use the log4j.configuration system property to define the properties files you want log4j to use.
A simple example for a file in some directory would be:
java -Dlog4j.configuration=file:/c:/foobar.properties YOUR CLASS PATH -jar JAR FILE
For more information check the documentation. Especially check the Default Initialization Procedure section.
I've looked through many of the existing threads about this error, but still no luck. I'm not even trying to package a jar or use any third-party packaging tools. I'm simply running from within Eclipse (works great) and then trying to run the exact same app from the command line, in the same location it's built to (getting this error). My goal is to be able to zip up the bin folder and send it off to be run by someone else via a command line script. Some details:
It's a command-line app and I'm using the commons-lang-2.4.jar for string utilities. That is the file that cannot be located (specificaly "java.lang.NoClassDefFoundError: org/apache/commons/lang/StringEscapeUtils")
I have that jar in my lib folder and have added it to my build path in Eclipse via right-click "Build Path -> Add to Build Path"
The .classpath file looks correct and contains the reference to the jar, but I assume that file is only used by Eclipse (contains this line: <classpathentry kind="lib" path="lib/commons-lang-2.4.jar"/>)
Could this be related to the Eclipse working directory setting? I have some internal template files that I created that are under src/templates, and the only way I can seem to get those to be seen is by setting the project working directory to AppName/src. Maybe I should be putting those somewhere else?
Let me know if any additional info would help. Surely this is something simple, but I've wasted too much time on it at this point. This is reminding me why I originally left Java back in '05 or so...
A NoClassDefFoundError basically means that the class was there in the classpath during compiletime, but it is missing in the classpath during runtime.
In your case, when executing using java.exe from commandline, you need to specify the classpath in the -cp or -classpath argument. Or if it is a JAR file, then you need to specify it in the class-path entry of its MANIFEST.MF file.
The value of the argument/entry can be either absolute or relative file system paths to a folder containing all .class files or to an individual .jar file. You can separate paths using a semicolon ;. When a path contains spaces, you need to wrap the particular path with doublequotes ". Example:
java -cp .;c:/path/to/file.jar;"c:/spacy path/to/classes" mypackage.MyClass
To save the effort of typing and editing the argument in commandline everytime, use a .bat file.
Edit: I should have realized that you're using an Unix based operating system. The above examples are Windows-targeted. In the case of Unix like platforms you can follow the same rules, but you need to separate the paths using a colon : and instead of an eventual batch file, use a .sh file.
java -cp .:/path/to/file.jar:"/spacy path/to/classes" mypackage.MyClass
Are you specifying the classpath to java on the command line?
$ java -cp lib/commons-lang-2.4.jar your.main.Class
The classpath setting you are setting in Eclispe are only for the IDE and do not affect how you application is run outside the IDE. Even if you use the Eclipse Functionality to export your application as an executable jar file there is no out of the box way to package all the jars your application depends on.
If you have packaged you application into a jar file called myapp.jar then running a command like below will run the application with the jar you depend on, if you have more than one just add them separted by ; on Windows or : on Unix:
java -jar myapp.jar -cp .;c:/pathtolibs/commons-lang-2.4.jar
If you are just running the classes directly then either run the folder containing your .class files will also need to be on the path (though I assume it already is since you are able to run the program and get errors).
Consider File -> Export -> Runnable jar to create a jar file which can be invoked directly with
java -jar yourProgram.jar
There are several variants depending on your needs.
Eclipse does not move any of the jars in your classpath into the bin folder of your project. You need to copy the util jar into the bin folder. If you move it to the root of the bin folder, you might be able to get away without any classpath entries but it's not the recommended solution. See #BalusC's answer for good coverage of that.
Eclipse doesn't build executable java classes by default. Don't ask me why, but it probably has something to do with using their own tools.jar (somewhere in plugins/org.eclipse.core ?) so that Eclipse can run without a JDK.
You can usually go to your project bin directory and do:
java -cp . MyClass
But if you have external jars, Eclipse handles those internally in another weird way, so you'll need to add those too.
make sure your jar commons-lang-2.4.jar in classpath and not redudance.
I ever add jar file to my classpath, and have 2 file jar in my classpath. After I delete it, work smooth