This question already has answers here:
Is it possible to mix --class-path and --module-path in javac (JDK 9)?
(2 answers)
Closed 3 years ago.
In previous versions of Java if you had for example a user-defined package org.mypackage in windows with directory structure
D:\myprogram\
|
---> org\
|
---> mypackage\
|
---> HelloWorld.class
---> SupportClass.class
---> UtilClass.class
you make the JVM aware of the package by using the CLASSPATH environment variable.
For example:
set CLASSPATH=D:\myprogram
Does set MODULEPATH command instead make the JVM aware of the location of user-defined modules in the latest versions of Java ?
If so why is classpath command still around and what purpose does it serve now?
No, the jdk does not read any MODULEPATH environment variable or similar.
The MODULEPATH only exists as a command-line argument --module-path, but not as an environment variable.
See http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009345.html
Unlike CLASSPATH, there is no equivalent MODULEPATH to get the option off of the command line.
Also see the linked question Is it possible to mix --class-path and --module-path in javac (JDK 9)? for more details on the differences between boths paths.
If you put a normal jar on the modulepath, it becomes an automatic module, exporting its packages (and reserving those packages for itself).
While you can put any normal jar file into the MODULEPATH, there is a restriction: If 2 jar files contain the same package, then java will not allow both of them in the modulepath. That's why Java still has the classpath, because several existing jar files still have overlapping packages, and it is not possible to put them all on the MODULEPATH. They have to be cleaned up first.
In the far future, when all libraries have been migrated to modules (or cleaned up), maybe classpath can be removed.
Related
I just installed Java on a Mac for the first time (jdk 10.0.2 SE) and I'm on macOS 10.13.6. I just created a basic Hello World program in my home directory, compiled it and ran it, but I have nothing set on my CLASSPATH environment variable except for the current directory "." My question is how am I able to compile and run this program? How is it finding the classes from the Java library? I've always assumed I need to set this variable, and I have it set to my jdk installation directory in Windows.
WHY DO WE SET THE CLASS-PATH?
well this is an riveting question.
it is self explanatory as
CLASSPATH is an environment variable and contain
paths to the jar files and path to various packages.
KISS ANSWER TO YOUR QUERY:
Perhaps ,the reason behind successful execution of
your code is that the JVM checks the current directory
first for the perception of jar files and then follows
the classpath .So your current directory has those files.
OH!You may wonder then why would we set the classpath
.Setting the classpath overrides that by default path.
Happy Learning :)
This question already has answers here:
Including all the jars in a directory within the Java classpath
(25 answers)
Closed 7 years ago.
I am trying to use a feature from the Apache Commons called StringUtils. However this requires you download the libary and add it so I can use the code import org.apache.commons.lang3.StringUtils;. My problem is I am unsure of where to add it to so that I may compile my program in command prompt. I am also unaware of what file I should to add into the required folder.
Any help would be greatly appreciated.
You'll have to make sure that the library (usually a JAR file) is in the classpath when you compile and run your application that uses the library.
The classpath is the set of JAR files and directories that Java uses to find Java class files.
See PATH and CLASSPATH in Oracle's Java Tutorials. (This is about setting the environment variables PATH and CLASSPATH).
As an alternative to setting the CLASSPATH environment variable, you can use the -cp or -classpath options of the javac and java commands:
javac -cp C:\MyProject\lib\somelibrary.jar;. com\mypackage\MyProgram.java
java -cp C:\MyProject\lib\somelibrary.jar;. com.mypackage.MyProgram
If you are not using any IDE, then include below line in your .java file.
import org.apache.commons.lang3.StringUtils;
then we you compile the .java class from cmd prompt, include the apache commons jar in classpath. like
javac -cp ../commons**.jar your_class.java
You will need the CLASSPATH environment variable to point to it. Link.
Given the context of the question I assume you are not using maven or an IDE. If you are there are simpler ways.
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.
This question already has answers here:
How to add directory to classpath in an application run profile in IntelliJ IDEA?
(8 answers)
Closed 9 years ago.
In IntelliJ, I have setup a runtime configuration for a Java (console) application. I need to add the directory c:/tmp to the classpath that the app is run with. I guess I need to add -cp c:/tmp to one of the boxes in this dialog, but I can't figure out which one:
Classpath is configured in the Module Dependencies.
The classpath is a VM parameter, so it should belong in there. However, I'm unsure whether you can overwrite the classpath at all using this technique...
If you want to specify the classpath for adding additional jars, you should use libraries instead.
Also, are you sure you want to change the classpath and not the working folder? (The classpath determines where to find classes, the working folder defines the starting directory of your application.)
This question already has answers here:
What is a classpath and how do I set it?
(10 answers)
Closed last year.
I am trying to compile a library I wrote, using javac and I am getting the error: package org.json does not exist. My program includes org.json.JSONArray and org.json.JSONException.
I have this package installed on my computer because I have successfully compiled android apps that import org.json libraries. I'm pretty sure all I have to do is specify a -classpath but I have been unable to find where these files live on my system (ubuntu 10.10 64-bit sun-java6).
Having been unable to find these on my own system I downloaded the org.json files from here, but I was unable to compile them individually because they were co-dependent on each other.
So I have a couple questions:
Does anyone know where the org.json
package lives from android sdk
install?
Where might I find a tutorial
explaining these basic concepts
regarding compiling, and javac.
Whatever external jars you need to compile with should be on the classpath when you compile. The most non-invasive way to do this is do add these items to the javac command line such as
javac -classpath /path/to/json.jar;. -g YourClass.java
or more likely if you use an IDE, add these jars to your referenced jars of the project in your IDE.
It usually isn't a good idea to pollute the global $CLASSPATH variable, as this then gets pulled in for everything you do with java, which may cause unintended conflicts.
Wherever you like. What you need to do is examine your CLASSPATH variable, and make sure it includes the directory with your library.
Here's the first thing:
$ echo $CLASSPATH
and you'll see your classpath as it is.
Now you need to find the jar file containing the org.json; consult the documentation, but it may be something as simple as json.jar. On most LINUX systems you can then just run
$ locate json.jar
And you'll get a path name for the jarfile. Make sure that path is part of your CLASSPATH and you'll be in fat city.
Oh, and the "Getting started" tutorials at Sun Oracle are the easiest place to start.
Actually, having looked at the files, they may not be packaged as a jar file. In that case, you want to put them into your sources starting at some top directory (src in this example.)
/src
/org/json/ ... put the json files here
... put your files here
and when you compile, they'll all be included, which will resolve all the dependencies.
Again, the place to look for first steps is that tutorial.
use "java" command instead of "javac"