When programming in Java, you make other classes available to the class you are writing by putting something like this at the top of your source file:
import org.javaguy.coolframework.MyClass;
Or sometimes you 'bulk import' stuff by saying:
import org.javaguy.coolframework.*;
So later in your program when you say:
MyClass mine = new MyClass();
The Java Virtual Machine will know where to find your compiled class.
It would be impractical to have the VM look through every folder on your machine, so you have to provide the VM a list of places to look. This is done by putting folder and jar files on your classpath.
Before we talk about how the classpath is set, let's talk about .class files, packages, and .jar files.
First, let's suppose that MyClass is something you built as part of your project, and it is in a directory in your project called output. The .class file would be at output/org/javaguy/coolframework/MyClass.class (along with every other file in that package). In order to get to that file, your path would simply need to contain the folder 'output', not the whole package structure, since your import statement provides all that information to the VM.
Now let's suppose that you bundle CoolFramework up into a .jar file, and put that CoolFramework.jar into a lib directory in your project. You would now need to put lib/CoolFramework.jar into your classpath. The VM will look inside the jar file for the org/javaguy/coolframework part, and find your class.
So, classpaths contain:
- JAR files, and
- Paths to the top of package hierarchies.
How do you set your classpath?
The first way everyone seems to learn is with environment variables. On a unix machine, you can say something like:
export CLASSPATH=/home/myaccount/myproject/lib/CoolFramework.jar:/home/myaccount/myproject/output/
On a Windows machine you have to go to your environment settings and either add or modify the value that is already there.
The second way is to use the -cp parameter when starting Java, like this:
java -cp "/home/myaccount/myproject/lib/CoolFramework.jar:/home/myaccount/myproject/output/" MyMainClass
A variant of this is the third way which is often done with a .sh or .bat file that calculates the classpath and passes it to Java via the -cp parameter.
There is a "gotcha" with all of the above. On most systems (Linux, Mac OS, UNIX, etc) the colon character (:) is the classpath separator. On Windows the separator is the semicolon (;)
So what's the best way to do it?
Setting stuff globally via environment variables is bad, generally for the same kinds of reasons that global variables are bad. You change the CLASSPATH environment variable so one program works, and you end up breaking another program.
The -cp is the way to go. I generally make sure my CLASSPATH environment variable is an empty string where I develop, whenever possible, so that I avoid global classpath issues (some tools aren't happy when the global classpath is empty though - I know of two common, mega-thousand dollar licensed J2EE and Java servers that have this kind of issue with their command-line tools).
java - What is a classpath and how do I set it? - Stack Overflow
How to read text file from classpath in Java? - Stack Overflow
Trying to understand classpath file
Understanding Java classpath.
What is classpath?
What is the purpose of setting a classpath in Java?
Does classpath work differently in modular Java applications?
Videos
When programming in Java, you make other classes available to the class you are writing by putting something like this at the top of your source file:
import org.javaguy.coolframework.MyClass;
Or sometimes you 'bulk import' stuff by saying:
import org.javaguy.coolframework.*;
So later in your program when you say:
MyClass mine = new MyClass();
The Java Virtual Machine will know where to find your compiled class.
It would be impractical to have the VM look through every folder on your machine, so you have to provide the VM a list of places to look. This is done by putting folder and jar files on your classpath.
Before we talk about how the classpath is set, let's talk about .class files, packages, and .jar files.
First, let's suppose that MyClass is something you built as part of your project, and it is in a directory in your project called output. The .class file would be at output/org/javaguy/coolframework/MyClass.class (along with every other file in that package). In order to get to that file, your path would simply need to contain the folder 'output', not the whole package structure, since your import statement provides all that information to the VM.
Now let's suppose that you bundle CoolFramework up into a .jar file, and put that CoolFramework.jar into a lib directory in your project. You would now need to put lib/CoolFramework.jar into your classpath. The VM will look inside the jar file for the org/javaguy/coolframework part, and find your class.
So, classpaths contain:
- JAR files, and
- Paths to the top of package hierarchies.
How do you set your classpath?
The first way everyone seems to learn is with environment variables. On a unix machine, you can say something like:
export CLASSPATH=/home/myaccount/myproject/lib/CoolFramework.jar:/home/myaccount/myproject/output/
On a Windows machine you have to go to your environment settings and either add or modify the value that is already there.
The second way is to use the -cp parameter when starting Java, like this:
java -cp "/home/myaccount/myproject/lib/CoolFramework.jar:/home/myaccount/myproject/output/" MyMainClass
A variant of this is the third way which is often done with a .sh or .bat file that calculates the classpath and passes it to Java via the -cp parameter.
There is a "gotcha" with all of the above. On most systems (Linux, Mac OS, UNIX, etc) the colon character (:) is the classpath separator. On Windows the separator is the semicolon (;)
So what's the best way to do it?
Setting stuff globally via environment variables is bad, generally for the same kinds of reasons that global variables are bad. You change the CLASSPATH environment variable so one program works, and you end up breaking another program.
The -cp is the way to go. I generally make sure my CLASSPATH environment variable is an empty string where I develop, whenever possible, so that I avoid global classpath issues (some tools aren't happy when the global classpath is empty though - I know of two common, mega-thousand dollar licensed J2EE and Java servers that have this kind of issue with their command-line tools).
Think of it as Java's answer to the PATH environment variable - OSes search for EXEs on the PATH, Java searches for classes and packages on the classpath.
With the directory on the classpath, from a class loaded by the same classloader, you should be able to use either of:
// From ClassLoader, all paths are "absolute" already - there's no context
// from which they could be relative. Therefore you don't need a leading slash.
InputStream in = this.getClass().getClassLoader()
.getResourceAsStream("SomeTextFile.txt");
// From Class, the path is relative to the package of the class unless
// you include a leading slash, so if you don't want to use the current
// package, include a slash like this:
InputStream in = this.getClass().getResourceAsStream("/SomeTextFile.txt");
If those aren't working, that suggests something else is wrong.
So for example, take this code:
package dummy;
import java.io.*;
public class Test
{
public static void main(String[] args)
{
InputStream stream = Test.class.getResourceAsStream("/SomeTextFile.txt");
System.out.println(stream != null);
stream = Test.class.getClassLoader().getResourceAsStream("SomeTextFile.txt");
System.out.println(stream != null);
}
}
And this directory structure:
code
dummy
Test.class
txt
SomeTextFile.txt
And then (using the Unix path separator as I'm on a Linux box):
java -classpath code:txt dummy.Test
Results:
true
true
When using the Spring Framework (either as a collection of utilities or container - you do not need to use the latter functionality) you can easily use the Resource abstraction.
Resource resource = new ClassPathResource("com/example/Foo.class");
Through the Resource interface you can access the resource as InputStream, URL, URI or File. Changing the resource type to e.g. a file system resource is a simple matter of changing the instance.
I just started learning Java so we have a study group where we are supposed to create a simple desktop application using Eclipse IDE and WindowBuilder.
I created the base project and then proceeded to push it to the shared repository. The rest of the people in the team tried executing the base project without success, while I could run it without any issues.
After a while, one of the members realized there is a problem with the classpatch file:
<?xml version="1.0" encoding="UTF-8"?>
<classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE\_CONTAINER"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/com.ibm.icu\_74.2.0.jar" sourcepath="/snap/eclipse/85/plugins/com.ibm.icu\_74.2.0.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/jakarta.annotation-api\_2.1.1.jar" sourcepath="/snap/eclipse/85/plugins/jakarta.annotation-api\_2.1.1.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.core.commands\_3.12.0.v20240214-1640.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.core.commands\_3.12.0.v20240214-1640.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.core.runtime\_3.31.0.v20240215-1631.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.core.runtime\_3.31.0.v20240215-1631.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.e4.ui.di\_1.5.300.v20240116-1723.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.e4.ui.di\_1.5.300.v20240116-1723.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.equinox.common\_3.19.0.v20240214-0846.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.equinox.common\_3.19.0.v20240214-0846.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.equinox.registry\_3.12.0.v20240213-1057.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.equinox.registry\_3.12.0.v20240213-1057.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.jface\_3.33.0.v20240214-1640.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.jface\_3.33.0.v20240214-1640.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.jface.text\_3.25.0.v20240207-1054.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.jface.text\_3.25.0.v20240207-1054.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.osgi\_3.19.0.v20240213-1246.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.osgi\_3.19.0.v20240213-1246.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.swt.gtk.linux.x86\_64\_3.125.0.v20240227-1638.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.swt.gtk.linux.x86\_64\_3.125.0.v20240227-1638.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.text\_3.14.0.v20240207-1054.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.text\_3.14.0.v20240207-1054.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.ui.forms\_3.13.200.v20240108-1539.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.ui.forms\_3.13.200.v20240108-1539.jar"/> <classpathentry kind="lib" path="/snap/eclipse/85/plugins/org.eclipse.ui.workbench\_3.131.100.v20240221-2107.jar" sourcepath="/snap/eclipse/85/plugins/org.eclipse.ui.workbench\_3.131.100.v20240221-2107.jar"/> <classpathentry kind="output" path="bin"/> </classpath>
This is making reference to several libs which exist only in my notebok, where I am using Ubuntu. They are trying to run it in Windows.
Is it not kind of stupid to refer to these libs this way? I am still trying to understanc why Java would make reference to these libs assuming all of us would be using Ubuntu? Nobody else in my team has the snap folder :/
Could you please help me understand what is going on? How can we fix it?
I tried looking for some videos explaining the classpath file but no luck so far.
Thank you :(
I was surfing stackoverflow, trying to better understand what the classpath is all about and came upon this question/answer. It mostly makes sense, but there are two slightly confusing paragraphs in the accepted answer that go:
First, let's suppose that MyClass is something you built as part of your project, and it is in a directory in your project called output. The .class file would be at output/org/javaguy/coolframework/MyClass.class (along with every other file in that package). In order to get to that file, your path would simply need to contain the folder 'output', not the whole package structure, since your import statement provides all that information to the VM.
Now let's suppose that you bundle CoolFramework up into a .jar file, and put that CoolFramework.jar into a lib directory in your project. You would now need to put lib/CoolFramework.jar into your classpath. The VM will look inside the jar file for the org/javaguy/coolframework part, and find your class.
I don't understand the two sentences that say:
You would now need to put lib/CoolFramework.jar into your classpath. The VM will look inside the jar file for the org/javaguy/coolframework part, and find your class.
Why would the VM "look inside the jar file for the org/javaguy/coolframework part"? Why does that structure exist within the jar file? The answer mentions that you bundle "CoolFramework up into a .jar file", so why would that include the org/javaguy/coolframework hierarchy? Isn't CoolFrameWork just a single directory?