Using Java 6 or later, the classpath option supports wildcards. Note the following:
- Use straight quotes (
"
)
- Use
*
, not *.jar
Windows
java -cp "Test.jar;lib/*" my.package.MainClass
Unix
java -cp "Test.jar:lib/*" my.package.MainClass
This is similar to Windows, but uses :
instead of ;
. If you cannot use wildcards, bash
allows the following syntax (where lib
is the directory containing all the Java archive files):
java -cp "$(printf %s: lib/*.jar)"
(Note that using a classpath is incompatible with the -jar
option. See also: Execute jar file with multiple classpath libraries from command prompt)
Understanding Wildcards
From the Classpath document:
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.
A class path entry that contains *
will not match class files. To
match both classes and JAR files in a single directory foo, use either
foo;foo/*
or foo/*;foo
. The order chosen determines whether the
classes and resources in foo
are loaded before JAR files in foo
, or
vice versa.
Subdirectories are not searched recursively. For example, foo/*
looks
for JAR files only in foo
, not in foo/bar
, foo/baz
, etc.
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 wildcards is done early, prior to the invocation of a
program's main method, rather than late, during the class-loading
process itself. Each element of the input class path containing 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 foo
contains a.jar
, b.jar
, and c.jar
, then
the class path foo/*
is expanded into foo/a.jar;foo/b.jar;foo/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
) command-line option. That is, wildcards are
honored in all these cases. However, class path wildcards are not
honored in the Class-Path jar-manifest
header.
Note: due to a known bug in java 8, the windows examples must use a backslash preceding entries with a trailing asterisk: https://bugs.openjdk.java.net/browse/JDK-8131329
public void listFilesForFolder(final File folder) {
for (final File fileEntry : folder.listFiles()) {
if (fileEntry.isDirectory()) {
listFilesForFolder(fileEntry);
} else {
System.out.println(fileEntry.getName());
}
}
}
final File folder = new File("/home/you/Desktop");
listFilesForFolder(folder);
Files.walk API is available from Java 8.
try (Stream<Path> paths = Files.walk(Paths.get("/home/you/Desktop"))) {
paths
.filter(Files::isRegularFile)
.forEach(System.out::println);
}
The example uses try-with-resources pattern recommended in API guide. It ensures that no matter circumstances the stream will be closed.
Best Answer
I would also suggest using some kind of build tool (Ant or Maven, Ant is already suggested and is easier to start with) or an IDE that handles the compilation (Eclipse uses incremental compilation with reconciling strategy, and you don't even have to care to press any "Compile" buttons).
Using Javac
If you need to try something out for a larger project and don't have any proper build tools nearby, you can always use a small trick that
javac
offers: the classnames to compile can be specified in a file. You simply have to pass the name of the file tojavac
with the@
prefix.If you can create a list of all the
*.java
files in your project, it's easy:sources.txt
file each time you create a new source or rename an existing one file which is an easy to forget (thus error-prone) and tiresome task.Using a build tool
On the long run it is better to use a tool that was designed to build software.
Using Ant
If you create a simple
build.xml
file that describes how to build the software:you can compile the whole software by running the following command:
Using Maven
Maven is not that trivial to set up and work with, but learning it pays well. Here's a great tutorial to start a project within 5 minutes.
Using an IDE
Now that what could boost your development productivity. There are a few open source alternatives (like Eclipse and NetBeans, I prefer the former) and even commercial ones (like IntelliJ) which are quite popular and powerful.
They can manage the project building in the background so you don't have to deal with all the command line stuff. However, it always comes handy if you know what actually happens in the background so you can hunt down occasional errors like a
ClassNotFoundException
.One additional note
For larger projects, it is always advised to use an IDE and a build tool. The former boosts your productivity, while the latter makes it possible to use different IDEs with the project (e.g., Maven can generate Eclipse project descriptors with a simple
mvn eclipse:eclipse
command). Moreover, having a project that can be tested/built with a single line command is easy to introduce to new colleagues and into a continuous integration server for example. Piece of cake :-)