I am looking for a way to run the standard class file as produced by Intellij for hello world, using a gradle build with kotlin-stdlib-1.3.11 as the only dependency.
I know I could make a jar file and run that but that is not the question. That question is already answered in many places, but please do not answer with those solutions as that is not the question I am asking.
The simple class file for 'hello world' needs access to the kotlin-stdlib-1.3.11.jar, and I am looking for a way to run the class file and manually specify jars to use for satisfying the dependencies.
I am making notes for team members on why:
java HelloKt
in folder where the class file is located, should give a NoClassDefFoundError and also looking to then show how manually specifying 'run the class but with the kotlin std lib as well' should then work.
I repeat, I am not trying to just get the program to run. I am trying to show how run the standard library is required to run the class file.
This is about the classpath.
The easy answer is to run kotlin instead of java, as that adds the Kotlin support to the classpath automatically:
> kotlin HelloKt
However, if you need to run java, then you'll need to set up the classpath yourself.
The manpage for java says:
The Java runtime searches for the startup class, and other classes used, in three sets of locations: the bootstrap class path, the installed extensions, and the user class path.
The first two are part of the Java installation, and rarely touched, so it's the user class path that you need to look at.
You need it to contain both kotlin-runner.jar and the path for your HelloKt.class file. The latter could simply be . for the current directory; the former will depend where you've installed Kotlin. (For example, I installed it using Homebrew, and that jar is currently /usr/local/Cellar/kotlin/1.3.31/libexec/lib/kotlin-runner.jar.)
The manpage continues:
-classpath classpath
-cp classpath
Specifies a list of directories, JAR archives, and ZIP archives
to search for class files. Class path entries are separated by
colons (:). Specifying -classpath or -cp overrides any setting
of the CLASSPATH environment variable.
If -classpath and -cp are not used and CLASSPATH is not set, the
user class path consists of the current directory (.).
So there are two ways you can do this: either set the $CLASSPATH environment variable before running java:
> export CLASSPATH="/usr/local/Cellar/kotlin/1.3.31/libexec/lib/kotlin-runner.jar:."
> java HelloKt
Or pass a -classpath or -cp flag:
> java -cp /usr/local/Cellar/kotlin/1.3.31/libexec/lib/kotlin-runner.jar:. HelloKt
(Or, as you say, you could build a jar file which includes the Kotlin support classes as well as your own. That's probably the best option if you're going to distribute it to machines which might not have Kotlin installed. But it's not the only option.)
As stated by #gidds, yes it is about the classpath.
The command java HelloKt is telling java the class to run is HelloKt, which is the class Kotlin uses to provide a containing class for an app called Hello, but that command does not identify where the code is that should be run. The code must be specified by the classpath. With the HelloKt.class file in the current directory, then '.' as a classpath with allow the HelloKt class to be found and the code to start, but it will quickly die because the repository 'kotlin-stdlib-1.3.11' as specified in the gradle build, must also be available to supply classes for run time. so
java -cp ".";"<path to stdlib>\kotlin-stdlib-1.3.11.jar"
will successfully run the file. Note, each jar must be a entry in the classpath, just having the folder containing the jar is not enough. On windows ';' separates entries, on mac or linux, use ':'. Each entry can be in quotes, and will need to be only if there are special characters in the path.
A common problem that new Java developers experience is that their programs fail to run with the error message: Could not find or load main class ...
What does this mean, what causes it, and how should you fix it?
The java <class-name> command syntax
First of all, you need to understand the correct way to launch a program using the java (or javaw) command.
The normal syntax1 is this:
java [ <options> ] <class-name> [<arg> ...]
where <option> is a command line option (starting with a "-" character), <class-name> is a fully qualified Java class name, and <arg> is an arbitrary command line argument that gets passed to your application.
1 - There are some other syntaxes which are described near the end of this answer.
The fully qualified name (FQN) for the class is conventionally written as you would in Java source code; e.g.
packagename.packagename2.packagename3.ClassName
However some versions of the java command allow you to use slashes instead of periods; e.g.
packagename/packagename2/packagename3/ClassName
which (confusingly) looks like a file pathname, but isn't one. Note that the term fully qualified name is standard Java terminology ... not something I just made up to confuse you :-)
Here is an example of what a java command should look like:
java -Xmx100m com.acme.example.ListUsers fred joe bert
The above is going to cause the java command to do the following:
Search for the compiled version of the com.acme.example.ListUsers class.
Load the class.
Check that the class has a main method with signature, return type and modifiers given by public static void main(String[]). (Note, the method argument's name is NOT part of the signature.)
Call that method passing it the command line arguments ("fred", "joe", "bert") as a String[].
Reasons why Java cannot find the class
When you get the message "Could not find or load main class ...", that means that the first step has failed. The java command was not able to find the class. And indeed, the "..." in the message will be the fully qualified class name that java is looking for.
So why might it be unable to find the class?
Reason #1 - you made a mistake with the classname argument
The first likely cause is that you may have provided the wrong class name. (Or ... the right class name, but in the wrong form.) Considering the example above, here are a variety of wrong ways to specify the class name:
Example #1 - a simple class name:
java ListUser
When the class is declared in a package such as com.acme.example, then you must use the full classname including the package name in the java command; e.g.
java com.acme.example.ListUser
Example #2 - a filename or pathname rather than a class name:
java ListUser.class
java com/acme/example/ListUser.class
Example #3 - a class name with the casing incorrect:
java com.acme.example.listuser
Example #4 - a typo
java com.acme.example.mistuser
Example #5 - a source filename (except for Java 11 or later; see below)
java ListUser.java
Example #6 - you forgot the class name entirely
java lots of arguments
Reason #2 - the application's classpath is incorrectly specified
The second likely cause is that the class name is correct, but that the java command cannot find the class. To understand this, you need to understand the concept of the "classpath". This is explained well by the Oracle documentation:
The java command documentation
Setting the Classpath.
The Java Tutorial - PATH and CLASSPATH
So ... if you have specified the class name correctly, the next thing to check is that you have specified the classpath correctly:
Read the three documents linked above. (Yes ... READ them! It is important that a Java programmer understands at least the basics of how the Java classpath mechanisms works.)
Look at command line and / or the CLASSPATH environment variable that is in effect when you run the java command. Check that the directory names and JAR file names are correct.
If there are relative pathnames in the classpath, check that they resolve correctly ... from the current directory that is in effect when you run the java command.
Check that the class (mentioned in the error message) can be located on the effective classpath.
Note that the classpath syntax is different for Windows versus Linux and Mac OS. (The classpath separator is ; on Windows and : on the others. If you use the wrong separator for your platform, you won't get an explicit error message. Instead, you will get a nonexistent file or directory on the path that will be silently ignored.)
Reason #2a - the wrong directory is on the classpath
When you put a directory on the classpath, it notionally corresponds to the root of the qualified name space. Classes are located in the directory structure beneath that root, by mapping the fully qualified name to a pathname. So for example, if "/usr/local/acme/classes" is on the class path, then when the JVM looks for a class called com.acme.example.Foon, it will look for a ".class" file with this pathname:
/usr/local/acme/classes/com/acme/example/Foon.class
If you had put "/usr/local/acme/classes/com/acme/example" on the classpath, then the JVM wouldn't be able to find the class.
Reason #2b - the subdirectory path doesn't match the FQN
If your classes FQN is com.acme.example.Foon, then the JVM is going to look for "Foon.class" in the directory "com/acme/example":
If your directory structure doesn't match the package naming as per the pattern above, the JVM won't find your class.
If you attempt rename a class by moving it, that will fail as well ... but the exception stacktrace will be different. It is liable to say something like this:
Caused by: java.lang.NoClassDefFoundError: <path> (wrong name: <name>)
because the FQN in the class file doesn't match what the class loader is expecting to find.
To give a concrete example, supposing that:
you want to run com.acme.example.Foon class,
the full file path is /usr/local/acme/classes/com/acme/example/Foon.class,
your current working directory is /usr/local/acme/classes/com/acme/example/,
then:
# wrong, FQN is needed
java Foon
# wrong, there is no `com/acme/example` folder in the current working directory
java com.acme.example.Foon
# wrong, similar to above
java -classpath . com.acme.example.Foon
# fine; relative classpath set
java -classpath ../../.. com.acme.example.Foon
# fine; absolute classpath set
java -classpath /usr/local/acme/classes com.acme.example.Foon
Notes:
The -classpath option can be shortened to -cp in most Java releases. Check the respective manual entries for java, javac and so on.
Think carefully when choosing between absolute and relative pathnames in classpaths. Remember that a relative pathname may "break" if the current directory changes.
Reason #2c - dependencies missing from the classpath
The classpath needs to include all of the other (non-system) classes that your application depends on. (The system classes are located automatically, and you rarely need to concern yourself with this.) For the main class to load correctly, the JVM needs to find:
the class itself.
all classes and interfaces in the superclass hierarchy (e.g. see Java class is present in classpath but startup fails with Error: Could not find or load main class)
all classes and interfaces that are referred to by means of variable or variable declarations, or method call or field access expressions.
(Note: the JLS and JVM specifications allow some scope for a JVM to load classes "lazily", and this can affect when a classloader exception is thrown.)
Reason #3 - the class has been declared in the wrong package
It occasionally happens that someone puts a source code file into the
the wrong folder in their source code tree, or they leave out the package declaration. If you do this in an IDE, the IDE's compiler will tell you about this immediately. Similarly if you use a decent Java build tool, the tool will run javac in a way that will detect the problem. However, if you build your Java code by hand, you can do it in such a way that the compiler doesn't notice the problem, and the resulting ".class" file is not in the place that you expect it to be.
Still can't find the problem?
There lots of things to check, and it is easy to miss something. Try adding the -Xdiag option to the java command line (as the first thing after java). It will output various things about class loading, and this may offer you clues as to what the real problem is.
Also, consider possible problems caused by copying and pasting invisible or non-ASCII characters from websites, documents and so on. And consider "homoglyphs", where two letters or symbols look the same ... but aren't.
You may run into this problem if you have invalid or incorrect signatures in META-INF/*.SF. You can try opening up the .jar in your favorite ZIP editor, and removing files from META-INF until all you have is your MANIFEST.MF. However this is NOT RECOMMENDED in general. (The invalid signature may be the result of someone having injected malware into the original signed JAR file. If you erase the invalid signature, you are in infecting your application with the malware!) The recommended approach is to get hold of JAR files with valid signatures, or rebuild them from the (authentic) original source code.
Finally, you can apparently run into this problem if there is a syntax error in the MANIFEST.MF file (see https://stackoverflow.com/a/67145190/139985).
Alternative syntaxes for java
There are three alternative syntaxes for the launching Java programs using the java command.
The syntax used for launching an "executable" JAR file is as follows:
java [ <options> ] -jar <jar-file-name> [<arg> ...]
e.g.
java -Xmx100m -jar /usr/local/acme-example/listuser.jar fred
The name of the entry-point class (i.e. com.acme.example.ListUser) and the classpath are specified in the MANIFEST of the JAR file.
The syntax for launching an application from a module (Java 9 and later) is as follows:
java [ <options> ] --module <module>[/<mainclass>] [<arg> ...]
The name of the entrypoint class is either defined by the <module> itself, or is given by the optional <mainclass>.
From Java 11 onwards, you can use the java command to compile and run a single source code file using the following syntax:
java [ <options> ] <sourcefile> [<arg> ...]
where <sourcefile> is (typically) a file with the suffix ".java".
For more details, please refer to the official documentation for the java command for the Java release that you are using.
IDEs
A typical Java IDE has support for running Java applications in the IDE JVM itself or in a child JVM. These are generally immune from this particular exception, because the IDE uses its own mechanisms to construct the runtime classpath, identify the main class and create the java command line.
However it is still possible for this exception to occur, if you do things behind the back of the IDE. For example, if you have previously set up an Application Launcher for your Java app in Eclipse, and you then moved the JAR file containing the "main" class to a different place in the file system without telling Eclipse, Eclipse would unwittingly launch the JVM with an incorrect classpath.
In short, if you get this problem in an IDE, check for things like stale IDE state, broken project references or broken launcher configurations.
It is also possible for an IDE to simply get confused. IDE's are hugely complicated pieces of software comprising many interacting parts. Many of these parts adopt various caching strategies in order to make the IDE as a whole responsive. These can sometimes go wrong, and one possible symptom is problems when launching applications. If you suspect this could be happening, it is worth trying other things like restarting your IDE, rebuilding the project and so on.
Other References
From the Oracle Java Tutorials - Common Problems (and Their Solutions)
If your source code name is HelloWorld.java, your compiled code will be HelloWorld.class.
You will get that error if you call it using:
java HelloWorld.class
Instead, use this:
java HelloWorld
If your classes are in packages then you have to cd to the root directory of your project and run using the fully qualified name of the class (packageName.MainClassName).
Example:
My classes are in here:
D:\project\com\cse\
The fully qualified name of my main class is:
com.cse.Main
So I cd back to the root project directory:
D:\project
Then issue the java command:
java com.cse.Main
This answer is for rescuing newbie Java programmers from the frustration caused by a common mistake. I recommend you read the accepted answer for more in depth knowledge about the Java classpath.
With keyword 'package'
If you have a package keyword in your source code (the main class is defined in a package), you should run it over the hierarchical directory, using the full name of the class (packageName.MainClassName).
Assume there is a source code file (Main.java):
package com.test;
public class Main {
public static void main(String[] args) {
System.out.println("salam 2nya\n");
}
}
For running this code, you should place Main.Class in the package like directory:
C:\Users\workspace\testapp\com\test\Main.Java
Then change the current directory of the terminal to the root directory of the project:
cd C:\Users\workspace\testapp
And finally, run the code:
java com.test.Main
Without keyword 'package'
If you don't have any package on your source code name maybe you are wrong with the wrong command. Assume that your Java file name is Main.java, after compile:
javac Main.java
your compiled code will be Main.class
You will get that error if you call it using:
java Main.class
Instead, use this:
java Main
When the same code works on one PC, but it shows the error in another, the best solution I have ever found is compiling like the following:
javac HelloWorld.java
java -cp . HelloWorld
Specifying the classpath on the command line helped me. For example:
Create a new folder, C:\temp
Create file Temp.java in C:\temp, with the following class in it:
public class Temp {
public static void main(String args[]) {
System.out.println(args[0]);
}
}
Open a command line in folder C:\temp, and write the following command to compile the Temp class:
javac Temp.java
Run the compiled Java class, adding the -classpath option to let JRE know where to find the class:
java -classpath C:\temp Temp Hello!
According to the error message ("Could not find or load main class"), there are two categories of problems:
The Main class could not be found
The Main class could not be loaded (this case is not fully discussed in the accepted answer)
The Main class could not be found when there is a typo or wrong syntax in the fully qualified class name or it does not exist in the provided classpath.
The Main class could not be loaded when the class cannot be initiated. Typically the main class extends another class and that class does not exist in the provided classpath.
For example:
public class YourMain extends org.apache.camel.spring.Main
If camel-spring is not included, this error will be reported.
Use this command:
java -cp . [PACKAGE.]CLASSNAME
Example: If your classname is Hello.class created from Hello.java then use the below command:
java -cp . Hello
If your file Hello.java is inside package com.demo then use the below command
java -cp . com.demo.Hello
With JDK 8 many times it happens that the class file is present in the same folder, but the java command expects classpath and for this reason we add -cp . to take the current folder as reference for classpath.
I had such an error in this case:
java -cp lib.jar com.mypackage.Main
It works with ; for Windows and : for Unix:
java -cp lib.jar; com.mypackage.Main
Try -Xdiag.
Steve C's answer covers the possible cases nicely, but sometimes to determine whether the class could not be found or loaded might not be that easy. Use java -Xdiag (since JDK 7). This prints out a nice stacktrace which provides a hint to what the message Could not find or load main class message means.
For instance, it can point you to other classes used by the main class that could not be found and prevented the main class to be loaded.
Sometimes what might be causing the issue has nothing to do with the main class, and I had to find this out the hard way. It was a referenced library that I moved, and it gave me the:
Could not find or load main class xxx Linux
I just deleted that reference, added it again, and it worked fine again.
I had same problem and finally found my mistake :)
I used this command for compiling and it worked correctly:
javac -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar" qrcode.java
But this command did not work for me (I could not find or load the main class, qrcode):
java -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar" qrcode
Finally I just added the ':' character at end of the classpath and the problem was solved:
java -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar:" qrcode
In this instance you have:
Could not find or load main class ?classpath
It's because you are using "-classpath", but the dash is not the same dash used by java on the command prompt. I had this issue copying and pasting from Notepad to cmd.
If you use Maven to build the JAR file, please make sure to specify the main class in the pom.xml file:
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>class name us.com.test.abc.MyMainClass</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
In my case, the error appeared because I had supplied the source file name instead of the class name.
We need to supply the class name containing the main method to the interpreter.
This might help you if your case is specifically like mine: as a beginner I also ran into this problem when I tried to run a Java program.
I compiled it like this:
javac HelloWorld.java
And I tried to run also with the same extension:
java Helloworld.java
When I removed the .java and rewrote the command like java HelloWorld, the program ran perfectly. :)
All answers here are directed towards Windows users it seems. For Mac, the classpath separator is :, not ;. As an error setting the classpath using ; is not thrown then this can be a difficult to discover if coming from Windows to Mac.
Here is corresponding Mac command:
java -classpath ".:./lib/*" com.test.MyClass
Where in this example the package is com.test and a lib folder is also to be included on classpath.
Class file location: C:\test\com\company
File Name: Main.class
Fully qualified class name: com.company.Main
Command line command:
java -classpath "C:\test" com.company.Main
Note here that class path does not include \com\company.
I thought that I was somehow setting my classpath incorrectly, but the problem was that I typed:
java -cp C:/java/MyClasses C:/java/MyClasses/utilities/myapp/Cool
instead of:
java -cp C:/java/MyClasses utilities/myapp/Cool
I thought the meaning of fully qualified meant to include the full path name instead of the full package name.
On Windows put .; at the CLASSPATH value in the beginning.
The . (dot) means "look in the current directory". This is a permanent solution.
Also you can set it "one time" with set CLASSPATH=%CLASSPATH%;.. This will last as long as your cmd window is open.
When running the java with the -cp option as advertised in Windows PowerShell you may get an error that looks something like:
The term `ClassName` is not recognized as the name of a cmdlet, function, script ...
In order to for PowerShell to accept the command, the arguments of the -cp option must be contained in quotes as in:
java -cp 'someDependency.jar;.' ClassName
Forming the command this way should allow Java process the classpath arguments correctly.
This is a specific case:
Windows (tested with Windows 7) doesn't accept special characters (like á) in class and package names. Linux does, though.
I found this out when I built a .jar in NetBeans and tried to run it in command line. It ran in NetBeans, but not on the command line.
What fixed the problem in my case was:
Right click on the project/class you want to run, and then Run As → Run Configurations. Then you should either fix your existing configuration or add a new one in the following way:
Open the Classpath tab, click on the Advanced... button, and then add bin folder of your project.
First set the path using this command;
set path="paste the set path address"
Then you need to load the program. Type "cd (folder name)" in the stored drive and compile it. For Example, if my program stored on the D drive, type "D:" press enter and type " cd (folder name)".
In Java, when you sometimes run the JVM from the command line using the Java interpreter executable and are trying to start a program from a class file with public static void main (PSVM), you might run into the below error even though the classpath parameter to the JVM is accurate and the class file is present on the classpath:
Error: main class not found or loaded
This happens if the class file with PSVM could not be loaded. One possible reason for that is that the class may be implementing an interface or extending another class that is not on the classpath. Normally if a class is not on the classpath, the error thrown indicates as such. But, if the class in use is extended or implemented, Java is unable to load the class itself.
Reference: https://www.computingnotes.net/java/error-main-class-not-found-or-loaded/
You really need to do this from the src folder. There you type the following command line:
[name of the package].[Class Name] [arguments]
Let's say your class is called CommandLine.class, and the code looks like this:
package com.tutorialspoint.java;
/**
* Created by mda21185 on 15-6-2016.
*/
public class CommandLine {
public static void main(String args[]){
for(int i=0; i<args.length; i++){
System.out.println("args[" + i + "]: " + args[i]);
}
}
}
Then you should cd to the src folder and the command you need to run would look like this:
java com.tutorialspoint.java.CommandLine this is a command line 200 -100
And the output on the command line would be:
args[0]: this
args[1]: is
args[2]: a
args[3]: command
args[4]: line
args[5]: 200
args[6]: -100
All right, there are many answers already, but no one mentioned the case where file permissions can be the culprit.
When running, a user may not have access to the JAR file or one of the directories of the path. For example, consider:
Jar file in /dir1/dir2/dir3/myjar.jar
User1 who owns the JAR file may do:
# Running as User1
cd /dir1/dir2/dir3/
chmod +r myjar.jar
But it still doesn't work:
# Running as User2
java -cp "/dir1/dir2/dir3:/dir1/dir2/javalibs" MyProgram
Error: Could not find or load main class MyProgram
This is because the running user (User2) does not have access to dir1, dir2, or javalibs or dir3. It may drive someone nuts when User1 can see the files, and can access to them, but the error still happens for User2.
I also faced similar errors while testing a Java MongoDB JDBC connection. I think it's good to summarize my final solution in short so that in the future anybody can directly look into the two commands and are good to proceed further.
Assume you are in the directory where your Java file and external dependencies (JAR files) exist.
Compile:
javac -cp mongo-java-driver-3.4.1.jar JavaMongoDBConnection.java
-cp - classpath argument; pass all the dependent JAR files one by one
*.java - This is the Java class file which has main method.
sdsd
Run:
java -cp mongo-java-driver-3.4.1.jar: JavaMongoDBConnection
Please do observe the colon (Unix) / comma (Windows) after all the dependency JAR files end
At the end, observe the main class name without any extension (no .class or .java)
I was unable to solve this problem with the solutions stated here (although the answer stated has, no doubt, cleared my concepts). I faced this problem two times and each time I have tried different solutions (in the Eclipse IDE).
Firstly, I have come across with multiple main methods in different classes of my project. So, I had deleted the main method from subsequent classes.
Secondly, I tried following solution:
Right click on my main project directory.
Head to source then clean up and stick with the default settings and on Finish. After some background tasks you will be directed to your main project directory.
After that I close my project, reopen it, and boom, I finally solved my problem.
Sometimes, in some online compilers that you might have tried you will get this error if you don't write public class [Classname] but just class [Classname].
Pretty basic problem here. So I have a Java package that I have created that has three classes (one has the main method). I am trying to use a few Apache Jars, and have added these to my build path in Eclipse. However Eclipse wont let me build and run it properly, so I am trying the command line. I have added the env var CLASSPATH and pointed it to my lib directory which hold the Apache Jars. However, when I try to use javac I get a bunch of errors:
package org.apache.xmlrpc does not exist
import org.apache.xmlrpc.client.XmlRpcClient;
I was reading the man page for javac and it said that:
If neither CLASSPATH, -cp nor -classpath is specified, the user class path consists of the current directory.
So I tried copying the Jars to the same location as my three source files, but no change.
Can someone please tell me what I'm doing wrong?
Thanks.
Classpath variable (or command line option of javac) must contain all jars explicitly. It cannot go through jar files stored in specified directory.
You can compile this by specifying the option -cp on the command line:
javac -cp foo.jar:bar.jar foo/bar/Baz.java
You then run it with the same option:
java -cp foo.jar:bar.jar foo.bar.Baz
It sounds like you've just set the classpath to the directory containing the jar files. You need to set it to the individual jar files, or use java.ext.dirs to set an "extension" directory containing jar files. I'd recommend using the specific jar files. Something like:
// Assuming Windows...
CLASSPATH = c:\libs\foo.jar;c:\libs\bar.jar
I'd also personally recommend specifying the classpath on the command line instead of using an environment variable - the latter will work, but it ends up being a bit more fiddly if you want to compile different projects against different libraries.
However, I'd actually recommend getting Eclipse working first, rather than retreating to the command line. It should be fine - if you could give us more information about what's failing in Eclipse, we may be able to help you with that instead.
The jar files in the current directory are not automatically included; that only refers to .class files in normal package/directory hierarchy. Jar files must be added either explicitly, or via a wildcard like javac -cp ./* (Assuming JDK6+)
(Some OSes may require an escape of the * to avoid globbing; OSX does not.)
I agree with previous answers, but I would also recommend to use proper java build tool - like ant (perceived easier to use, but not necessary) or maven ( perceived more difficult to use, but really worth learning )
In my code I have the following statement import com.apple.dnssd.*; and compiler (javac) complains about this line. It writes that the package does not exist. But I think that it could be that "javac" search the package in a wrong place (directory). In this respect I have two questions:
How can I know where javac search for the packages?
I think that it is very likely that I have the above mentioned package but I do not know where it is located. What are the typical place to look for the packages?
ADDED:
On another Windows machine I tried the same thing and the "javac" does not complain (as before I compiled without any options like "-cp"). I check values of the "classpath" environment variable. It is equal to "C:\Program Files\Java\jdk1.6.0_18\bin;.;..". I went to the first classpath directory and did not find there something that could be the "com.apple.dnssd" library (no jar files, no files containing "apple"). So, I do not understand why javac do NOT complain on the second Windows machine.
ADDED 2:
On the machine #2 I have installed Bonjour after JDK. On the machine #1 JDK was installed after Bonjour.
ADDED 3:
On the machine #1 (where I cannot import the package) I found the jar file (it is located in "C:\Program Files\Bonjour" and its name is "dns_sd.jar"). I tried to add the above mentioned directory to the PATHCLASS environment variable on Windows 7 (and I restarted the system). It does not help. I still cannot import the package. I also tried to specify the "-classpath" in the command line. It also does not help. Now I will try to reinstall Bonjour (as it was advised).
ADDED 4:
I have uninstall Bonjour and Bonjour SDK. I have reload Window. Then I have installed Bonjour and Bonjour SDK. I have reload the Window. It did not solve the problem. I still cannot import the package (javac writes that package does not exist). I have also copied the *.jar file to the same directory there the source is located. It does not work. I used "javac -cp .". It does not work. Now I am out of options. I do not know what else can I try. Can anybody help me pleas?
ADDED 5:
My classpath is: C:\Program Files\Java\jdk1.6.0_18\bin;.;..;"C:\Program Files\Bonjour"
I try to compile from this directory: C:\Users\myname\java\bonjour\example
I compile by the following command: javac ServiceAnnouncer.java
I get the following error message: ServiceAnnouncer.java:1: package com.apple.dnssd does not exist
ADDED 6:
Finally I have managed to import the library. I did it in the following way:
javac -cp "C:\Program Files\Bonjour\dns_sd.jar" ServiceAnnouncer.java
The important thing is that I have specified the jar file after the -cp (not the directory where the jar file is located). It works also if I replace "dns_sd.jar" by "*". So, my conclusion is that after the "-cp" I need to specify jar files (not directories).
Java/javac will search for classes in the classpath.
The default classpath covers the /path/to/jre/lib and /path/to/jre/lib/ext folders. Any classes and JAR files which are found there will be taken in the classpath. You can in theory put your classes and JAR files there so that you don't need to do anything to get java/javac to find them. But this is actually an extremely bad practice. It's recipe for portability trouble, because this isn't the same in all machines. Leave those folders intact.
Then there's the environment variable %CLASSPATH% wherein you can specify full paths to root folders where classes are located and/or full paths to JAR files (including the JAR file name itself!). Multiple paths are in Windows to be separated by semicolon ; and in *Nix by colon :. Paths with spaces inside needs to be quoted with "". Here's an example:
SET CLASSPATH = .;/path/to/File.jar;"/spacy path to some pkg/with/classes"
Note the period . at the beginning of the argument. This indicates the current path (the current working directory from where the java/javac command is to be executed). It will only find classes in the current path that way, and thus not JAR files! You need to specify full path for them. Since Java 1.6 you can also use wildcards to specify multiple JAR files in some path. E.g.
SET CLASSPATH = .;/path/to/all/jars/*;"/spacy path to some pkg/with/classes"
This environment variable is actually a convenience way to manage the classpath so that you don't need to type the same thing down again and again in the command console everytime. But this is only useful for new-to-java users and the cause of all future confusion because they will think that this is "the" classpath. This assumption is actually wrong and again the cause of portability trouble because this isn't the same in all machines.
The right way to define the classpath is using the -cp or -classpath argument wherein you actually specify the same information as you'd like to enter for %CLASSPATH%, i.e. (semi)colon separated and paths-with-spaces quoted, for example:
javac -cp .;/path/to/File.jar;"/spacy path to some pkg/with/classes" Foo.java
Note that when you use either -cp or -classpath (or -jar) arguments, then java/javac will ignore the %CLASSPATH% environment variable (which is actually a Good ThingTM).
To save the time in retyping the same again and again, just create a bat or cmd file (or if you're on *Nix, a sh file). Basically just put therein the same commands as you'd enter "plain" in the console and then execute it the usual platform specific way.
To save more time, use an IDE. The classpath which is to be used during both compiletime and runtime inside the IDE is called the "build path". Explore the project properties and you'll see.
http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html
To answer your first question (How to know where javac searches for packages):
Check what your $CLASSPATH variable is set to.
echo $CLASSPATH
This is where you JRE will search for class files and resources. You can either set it as an environment variable,
set CLASSPATH=path1;path2 ...
or set it when your run javac.
C:> javac -classpath C:\java\MyClasses src_dir
(Great examples for javac are found here)
In this case, your jar file containing 'com.apple.dnssd.*' should be located in your classpath. Just download that jar, and put it in the place where your classpath is searching.
Assuming that dns_sd.jar is installed in 'C:\Program Files\Bonjour', then try to compile your code like this:
cd C:\Users\myname\java\bonjour\example
javac -classpath C:\Program Files\Bonjour ServiceAnnouncer.java
This link suggests that the JAR containing this package is part of Bonjour for Windows. Look for it there.
javac.exe only searches where you tell it with the CLASSPATH. If you don't understand how to set CLASSPATH, I'd recommend reading something like this.
I was just reading this line:
The first thing the format() method does is load a Velocity template from the classpath named output.vm
Please explain what was meant by classpath in this context, and how I should set the classpath.
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. In windowsm 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.
The classpath is one of the fundamental concepts in the Java world and it's often misunderstood or not understood at all by java programmes, especially beginners.
Simply put, the classpath is just a set of paths where the java compiler and the JVM must find needed classes to compile or execute other classes.
Let's start with an example, suppose we have a Main.java file thats under C:\Users\HP\Desktop\org\example,
package org.example;
public class Main {
public static void main(String[] args) {
System.out.println("Hello world");
}
}
And Now, suppose we are under C:\ directory and we want to compile our class, Its easy right, just run:
javac .\Users\HP\Desktop\org\example\Main.java
Now for the hard question, we are in the same folder C:\ and we want to run the compiled class.
Despite of what you might think of to be the answer, the right one is:
java -cp .\Users\HP\Desktop org.example.Main
I'll explain why, first of all, the name of the class that we want ro tun is org.exmaple.Main not Main, or Main.class or .\users\hp\desktop\org\example\Main.class ! This is how things works with classes declared under packages.
Now, we provided the name of the class to the JVM (java command in this case), But how it (JVM) will know where to find the .class file for the Main class? Thats where the classpath comes into picture. Using -cp flag (shortcut for -classpath), we tell the JVM that our Main.class file will be located at C:\users\hp\Desktop.. In fact, not really, we tell it to just go to the Desktop directory, and, because of the name of the class org.example.Main, the JVM is smart and it will go from Desktop to org directory, and from org to example directory, searching for Main.class file, and it will find it and it will kill it, I mean, it will run it :D .
Now lets suppose that inside the Main class we want to work with another class named org.apache.commons.lang3.StringUtils and the latter is located in a jar file named commons-lang3-3.10.jar thats inside C:\Users\HP\Downloads. So Main.java will look like this now:
package org.example;
import org.apache.commons.lang3.StringUtils;
public class Main {
public static void main(String[] args) {
System.out.println("Hello world");
System.out.println(StringUtils.equals("java", "java")); //true
}
}
How to compile the Main.java if we are always inside C:\ ? The answer is:
javac -cp .\Users\HP\Downloads\commons-lang3-3.10.jar .\Users\HP\Desktop\org\example\Main.java
.\Users\HP\Desktop\org\example\Main.java is because our .java file is there in the filesystem.
-cp .\Users\HP\Downloads\commons-lang3-3.10.jar is because the java compiler (javac in this case) need to know the location of the class org.apache.commons.lang3.StringUtils, so we provided the path of the jar file, and the compiler will then go inside the jar file and try to find a file StringUtils.class inside a directory org\apache\commons\lang3.
And if we want to run the Main.class file, we will execute:
java -cp ".\Users\HP\Desktop\;.\Users\HP\Downloads\commons-lang3-3.10.jar" org.example.Main
org.example.Main is the name of the class.
".\Users\HP\Desktop\;.\Users\HP\Downloads\commons-lang3-3.10.jar" are the paths (separated by ; in Windows) to the Main and StringUtils classes.
The classpath is the path where the Java Virtual Machine look for user-defined classes, packages and resources in Java programs.
In this context, the format() method load a template file from this path.
The classpath in this context is exactly what it is in the general context: anywhere the VM knows it can find classes to be loaded, and resources as well (such as output.vm in your case).
I'd understand Velocity expects to find a file named output.vm anywhere in "no package". This can be a JAR, regular folder, ... The root of any of the locations in the application's classpath.
Setting the CLASSPATH System Variable
To display the current CLASSPATH variable, use these commands in Windows and UNIX (Bourne shell):
In Windows: C:\> set CLASSPATH
In UNIX: % echo $CLASSPATH
To delete the current contents of the CLASSPATH variable, use these commands:
In Windows: C:\> set CLASSPATH=
In UNIX: % unset CLASSPATH; export CLASSPATH
To set the CLASSPATH variable, use these commands (for example):
In Windows: C:\> set CLASSPATH=C:\users\george\java\classes
In UNIX: % CLASSPATH=/home/george/java/classes; export CLASSPATH
Classpath is an environment variable of system. The setting of this variable is used to provide the root of any package hierarchy to java compiler.
CLASSPATH is an environment variable (i.e., global variables of the operating system available to all the processes) needed for the Java compiler and runtime to locate the Java packages used in a Java program. (Why not call PACKAGEPATH?) This is similar to another environment variable PATH, which is used by the CMD shell to find the executable programs.
CLASSPATH can be set in one of the following ways:
CLASSPATH can be set permanently in the environment: In Windows, choose control panel ⇒ System ⇒ Advanced ⇒ Environment Variables ⇒ choose "System Variables" (for all the users) or "User Variables" (only the currently login user) ⇒ choose "Edit" (if CLASSPATH already exists) or "New" ⇒ Enter "CLASSPATH" as the variable name ⇒ Enter the required directories and JAR files (separated by semicolons) as the value (e.g., ".;c:\javaproject\classes;d:\tomcat\lib\servlet-api.jar"). Take note that you need to include the current working directory (denoted by '.') in the CLASSPATH.
To check the current setting of the CLASSPATH, issue the following command:
> SET CLASSPATH
CLASSPATH can be set temporarily for that particular CMD shell session by issuing the following command:
> SET CLASSPATH=.;c:\javaproject\classes;d:\tomcat\lib\servlet-api.jar
Instead of using the CLASSPATH environment variable, you can also use the command-line option -classpath or -cp of the javac and java commands, for example,
> java –classpath c:\javaproject\classes com.abc.project1.subproject2.MyClass3
For linux users, and to sum up and add to what others have said here, you should know the following:
$CLASSPATH is what Java uses to look through multiple directories to find all the different classes it needs for your script (unless you explicitly tell it otherwise with the -cp override). Using -cp requires that you keep track of all the directories manually and copy-paste that line every time you run the program (not preferable IMO).
The colon (":") character separates the different directories. There is only one $CLASSPATH and it has all the directories in it. So, when you run "export CLASSPATH=...." you want to include the current value "$CLASSPATH" in order to append to it. For example:
export CLASSPATH=.
export CLASSPATH=$CLASSPATH:/usr/share/java/mysql-connector-java-5.1.12.jar
In the first line above, you start CLASSPATH out with just a simple 'dot' which is the path to your current working directory. With that, whenever you run java it will look in the current working directory (the one you're in) for classes. In the second line above, $CLASSPATH grabs the value that you previously entered (.) and appends the path to a mysql dirver. Now, java will look for the driver AND for your classes.
echo $CLASSPATH
is super handy, and what it returns should read like a colon-separated list of all the directories, and .jar files, you want java looking in for the classes it needs.
Tomcat does not use CLASSPATH. Read what to do about that here: https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html
Static member of a class can be called directly without creating object instance.
Since the main method is static Java virtual Machine can call it without creating any instance of a class which contains the main method, which is start point of program.