Class path entries can contain the base name wildcard character (), which is considered equivalent to specifying a list of all of the files in the directory with the extension .jar or .JAR. For example, the class path entry mydir/ specifies all JAR files in the directory named mydir. A class path entry consisting of * expands to a list of all the jar files in the current directory. Files are considered regardless of whether they are hidden (have names beginning with ‘.’). A class path entry that contains an asterisk () does not match class files. To match both classes and JAR files in a single directory mydir, use either mydir:mydir/ or mydir/*:mydir. The order chosen determines whether the classes and resources in mydir are loaded before JAR files in mydir or vice versa. Subdirectories are not searched recursively. For example, mydir/* searches for JAR files only in mydir, not in mydir/subdir1, mydir/subdir2, and so on. The order in which the JAR files in a directory are enumerated in the expanded class path is not specified and may vary from platform to platform and even from moment to moment on the same machine. A well-constructed application should not depend upon any particular order. If a specific order is required, then the JAR files can be enumerated explicitly in the class path. Expansion of wild cards is done early, before the invocation of a program’s main method, rather than late, during the class-loading process. Each element of the input class path that contains a wildcard is replaced by the (possibly empty) sequence of elements generated by enumerating the JAR files in the named directory. For example, if the directory mydir contains a.jar, b.jar, and c.jar, then the class path mydir/* is expanded into mydir/a.jar:mydir/b.jar:mydir/c.jar, and that string would be the value of the system property java.class.path. The CLASSPATH environment variable is not treated any differently from the -classpath or -cp options. Wild cards are honored in all of these cases. However, class path wild cards are not honored in the Class-Path jar-manifest header.

When classes are stored in a directory (folder), such as c:\java\MyClasses\utility\myapp, then the class path entry points to the directory that contains the first element of the package name (in this case, C:\java\MyClasses, because the package name is utility.myapp). When classes are stored in an archive file (a zip or JAR file) the class path entry is the path to and including the zip or JAR file. For example, the command to use a class library that is in a JAR file as follows:

To find class files in the directory C:\java\MyClasses and classes in C:\java\OtherClasses, you would set the class path to the following. Note that the two paths are separated by a semicolon.

The order in which you specify multiple class path entries is important. The Java interpreter will look for classes in the directories in the order they appear in the class path variable. In the previous example, the Java interpreter will first look for a needed class in the directory C:\java\MyClasses. Only when it does not find a class with the proper name in that directory will the interpreter look in the C:\java\OtherClasses directory.

From: docs.oracle.com