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.
Related
I am trying to run a simple Java application in Unix. My Java application read a config file from a directory at run-time. I placed the files in /tmp/paddy/. I created a simple bash script to run a application.
I tried like below and it gives me "no main manifest attribute, in app.jar" error
#!/bin/bash
java -cp ".:./config/*.*" -jar "app.jar" com.test.MainClass
And tried with below command This time my application is running but couldnt find the aconfig file so it throw me NullPointerException - (since it couldnt load the config file)
#!/bin/bash
java -cp app.jar com.test.MainClass
What is the correct way to override classpath in Java -cp command ? I was searching over the internet, but couldnt get any good answers. I dont have any issues running in windows. Only in linux and I am pretty new to the linux environment.
You have four separate issues here.
-jar and -cp don't work together
If you use the -jar switch, the classpath is taken from the Class-Path manifest entry in the jar's manifest, and that is all that will happen - the -cp switch (and the CLASSPATH environment variable) are completely ignored. The solution is to fix your jarfile, which ought to have that classpath entry.
That's not how bash works.
Separate from that issue, your -cp parameter is broken.
*.* in.. linux...? That's late 90s DOS, mate!
It's java doing the parsing of that *, which is unique, because in linux it's normally bash doing it, but that doesn't work here, because bash will be adding spaces, and java needs colons/semicolons, which is why java does it itself. The point is, java is rather limited and only understands a single *. Which bash will mess up. So, there is really only one way to do this.
Single quotes.
One star.
For example:
java -cp '.:./config/*' com.test.MainClass
You don't seem to understand how classpaths work
Each individual entry in a classpath must be either:
A directory which contains classfiles.
A jar file
Note how it specifically cannot be 'a directory that contains jar files', and also cannot be 'a class file'; that is not a thing. The * is the usual treatment: It takes every file in the directory you padded with /* and considers them all to be part of the classpath.
So, if you write: java -cp ., that will not include app.jar. If you write java -cp './config/*', that will not include any class or config files hanging off of ./config (only jar files located there).
That's not how config files work
Including config files on the classpath is not how its done. You can, of course. This doesn't do anything whatsoever, unless you are using SomeClass.class.getResource or some other variant of getResource (those are no good, you should be using SomeClass.class.getResource or SomeClass.class.getResourceAsStream, but I digress), in which case, don't do that. Those aren't intended for config files, those are for static files (files that never change, such as, say, a 'save to cloud' icon for your swing user interface application). If you are doing that, you'd need to include ./config (and not './config/*') in your classpath, but it would be a better idea to fix your code.
config files should be in the user's home directory - System.getProperty("user.home"). You should consider the directory that contains the jar file(s) as the place where the executables live, and those are not necessarily editable by the user, and surely the point of a config file is that you can edit them. Hence why using the classpath for these is not how it is done.
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 seen several very similar questions on stackoverflow, but haven't come across anything that exactly matches my problem. I have a folder with several .java files, and another folder with two .jar files. I need to include both the jar files while using javac so that the entire project gets compiled at one go:
$: javac -classpath .:~/myjardir/*.jar ~/myprojectdir/*.java
But if I do this, only the first jar is recognized, and everything that depends on the second jar throws an error. Surprisingly, if I compile each program separately,
$: javac -classpath .:~/myjardir/oneofthejars.jar ~/myprojectdir/file1.java
then everything works fine. I have also compiled the project separately in Eclipse just to test the code and the jars. It is only when I try to use both the jars with -classpath in command line that I get the errors. Wildcard entries are supposed to work in JDK6, so I am at a loss here.
The class path wildcards don't work like they do in the Unix shells. The * means everything named *.jar in the directory. So you don't need to do *.jar but just *. The following should do what you want:
$: javac -classpath .:~/myjardir/* ~/myprojectdir/*.java
See Understanding class path wildcards in the Java SE 6 documentation.
see the SO answer here but here's the relevant paragraph from the Java documentation:
Class path entries can contain the basename wildcard character *, which is considered equivalent to specifying a list of all the files in the directory with the extension .jar or .JAR. For example, the class path entry foo/** specifies all JAR files in the directory named foo. A classpath entry consisting simply of * expands to a list of all the jar files in the current directory.
if you want multiple things in a classpath, you have to separate them by the classpath separator as far as I know. So ./lib:/lib/mylib would be a valid classpath on a unix system, I think the equivalent would be .\lib;\lib\mylib on a windows system. You don't have to specify every file, just the directories.
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.
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.