The javac tool reads class and interface definitions, written in
the Java programming language, and compiles them into bytecode class
files.
There are two ways to pass source code file names to javac:
For a small number of source files, simply list the file names on the
command line.
For a large number of source files, list the the file names in
a file, separated by blanks or line breaks. Then use the list file
name on the javac command line, preceded by an @
character.
Source code file names must have .java suffixes,
class file names must have .class suffixes, and both
source and class files must have root names that identify the class. For
example, a class called MyClass would be written in a
source file called MyClass.java and compiled into a
bytecode class file called MyClass.class.
Inner class definitions
produce additional class files. These class files have names combining
the inner and outer class names, such as
MyClass$MyInnerClass.class.
You should arrange source files in a directory tree that reflects their
package tree. For example, if you keep all your source files in
/workspace, the source code for
com.mysoft.mypack.MyClass should be in
/workspace/com/mysoft/mypack/MyClass.java.
By default, the compiler puts each class file in the same directory as
its source file. You can specify a separate destination directory with
-d (see Options, below).
When compiling a source file, the compiler often needs information
about a type it does not yet recognize. The compiler needs type
information for every class or interface used, extended, or implemented
in the source file. This includes classes and interfaces not explicitly
mentioned in the source file but which provide information through
inheritance.
For example, when you subclass java.applet.Applet, you are also
using Applet's ancestor classes: java.awt.Panel,
java.awt.Container, java.awt.Component, and
java.awt.Object.
When the compiler needs type information, it
looks for a source file or class file which defines the type.
The compiler searches first in the
bootstrap and extension classes, then
in the user class path. The user class path is defined by setting the
CLASSPATH environment variable or by using the -classpath
command line option. (For details, see
Setting the Class Path). If you use the -sourcepath option, the compiler
searches the indicated path for source files; otherwise the compiler
searches the user class path both for class files and source files.
You can specify different bootstrap or extension classes with the
-bootclasspath and -extdirs options; see
Cross-Compilation Options below.
A successful type search may produce a class file, a source file, or
both. Here is how javac handles each situation:
Search produces a class file but no source file:javac uses the class file.
Search produces a source file but no class file:javac compiles the source file and uses the resulting class
file.
Search produces both a source file and a class file:javac determines whether the class file is out of date. If
the class file is out of date, javac recompiles the source
file and uses the updated class file. Otherwise, javac just
uses the class file.
By default, javac considers a class file out of date only if
it is older than the source file. (The -Xdepend option
specifies a slower but more reliable procedure.)
Note that javac can silently compile source files not mentioned
on the command line. Use the -verbose option to trace automatic
compilation.
FILE LIST
-->
To shorten or simplify the javac command, you may specify
one or more files that themselves contain one filename per line. On
the command line, use the '@' character with the filename to
specify it as a file list. When javac encounters an argument
beginning with the character `@', it operates on the
filenames in that file as if they had been on the command line.
For example, you can list all of the source file names in a file
named sourcefiles. This file might look like:
The compiler has a set of standard options that are supported on the
current development environment and will be supported in future releases.
An additional set of non-standard options are specific to the current
virtual machine and compiler implementations and are subject to change
in the future. Non-standard options begin with -X.
Set the user class path, overriding the user class path in
the CLASSPATH environment variable. If neither
CLASSPATH or -classpath is specified, the user
class path consists of the current directory. See
Setting the Class Path for more details.
If the -sourcepath option is not specified, the user
class path is searched for source files as well as class files.
-ddirectory
Set the destination directory for class files. If a class
is part of a package, javac puts the class file in a
subdirectory reflecting the package name, creating directories
as needed. For example, if you specify -d /home/myclasses
and the class is called com.mypackage.MyClass,
then the class file is called
/home/myclasses/com/mypackage/MyClass.class.
If -d is not specified, javac puts the class file
in the same directory as the source file.
Note that the directory specified by -d is not
automatically added to your user class path.
-deprecation
Show a description of each use or override of a deprecated
member or class. Without -deprecation, javac
shows the names of source files that use or override deprecated
members or classes.
-encoding
Set the source file encoding name, such as
EUCJIS/SJIS. If -encoding is not specified,
the platform default converter is used.
-g
Generate all debugging information, including local variables.
By default, only line number and source file information is generated.
-g:none
Do not generate any debugging information.
-g:{keyword list}
Generate only some kinds of debugging information, specified
by a comma separated list of keywords. Valid keywords are:
source
Source file debugging information
lines
Line number debugging information
vars
Local variable debugging information
-nowarn
Disable warning messages.
-O
Note: the -O option does nothing in the current
implementation of javac and oldjavac.
Optimize code for execution time. Using the -O
option may slow down compilation, produce larger class files,
and make the program difficult to debug.
Prior to the Java 2 SDK v1.2, the -g and -O options of javac could not be used
togther. As of the Java 2 SDK v1.2, you can combine -g and -O, but you may
get suprising results, such as missing variables or relocated or missing
code. -O no longer automatically turns on
-depend or turns off -g.
-sourcepathsourcepath
Specify the source code path to search for class or
interface definitions. As with the user class path, source path
entries are separated by colons (:) and can be
directories, JAR archives, or ZIP archives. If packages are
used, the local path name within the directory or archive must
reflect the package name.
Note that classes found through the classpath are subject to
automatic recompilation if their sources are found.
-verbose
Verbose output. This includes information about each class
loaded and each source file compiled.
By default, classes are compiled against the bootstrap and
extension classes of the platform that javac shipped with.
But javac also
supports cross-compiling, where classes are compiled against a
bootstrap and extension classes of a different Java platform
implementation. It is important to use -bootclasspath and
-extdirs when cross-compiling; see
Cross-Compilation Example below.
-targetversion
Generate class files that will work on VMs with the specified
version. The default is to generate class files to be compatible
with both 1.1 VMs and VMs in the Java 2 SDK.
The versions supported by javac in the Java 2 SDK are:
1.1
Ensure that generated class files will be compatible with 1.1
and VMs in the Java 2 SDK. This is the default.
1.2
Generate class files that will run on VMs in the Java 2 SDK, v 1.2
and later, but will not run on 1.1 VMs.
1.3
Generate class files that will run on VMs in the Java 2 SDK, v 1.3
and later, but will not run on 1.1 or 1.2 VMs.
-bootclasspathbootclasspath
Cross-compile against the specified set of boot classes. As
with the user class path, boot class path entries are separated
by colons (:) and can be directories, JAR archives,
or ZIP archives.
-extdirsdirectories
Cross-compile against the specified extension directories.
Directories is a colon-separated list of
directories. Each JAR archive in the specified directories is
searched for class files.
These options are supported only by oldjavac. They are not
supported by the new javac compiler.
-X
Display information about non-standard options and exit.
-Xdepend
Recursively search all reachable classes for more recent
source files to recompile. This option will more reliably
discover classes that need to be recompiled, but can slow down the
compilation process drastically.
-Xstdout
Send compiler messages to System.out. By
default, compiler messages go to System.err.
-Xverbosepath
Describe how paths and standard extensions were searched to find
source and class files.
The -J option
Both javac and oldjavac support the -J option.
-Joption
Pass option to the java launcher called by
javac. For example, -J-Xms48m sets the startup
memory to 48 megabytes.
Although it does not begin with -X, it is not a `standard
option' of javac.
It is a common convention for -J to pass options
to the underlying VM executing applications written in Java.
Note that CLASSPATH, -classpath, -bootclasspath,
and -extdirs do not specify the classes used to run
javac. Fiddling with the implementation of the compiler in this
way is usually pointless and always risky. If you do need to do this,
use the -J option to pass through options to the underlying
java launcher.
One source file, Hello.java, defines a class called
greetings.Hello. The greetings directory is the
package directory both for the source file and the class file and is
off the current directory. This allows us to use the default user class
path. It also makes it unnecessary to specify a separate destination
directory with -d.
% ls
greetings/
% ls greetings
Hello.java
% cat greetings/Hello.java
package greetings;
public class Hello {
public static void main(String[] args) {
for (int i=0; i < args.length; i++) {
System.out.println("Hello " + args[i]);
}
}
}
% javac greetings/Hello.java
% ls greetings
Hello.class Hello.java
% java greetings.Hello World Universe Everyone
Hello World
Hello Universe
Hello Everyone
Having changed one of the source files in the previous example, we
recompile it:
% pwd
/examples
% javac greetings/Hi.java
Since greetings.Hi refers to other classes in the
greetings package, the compiler needs to find these other
classes. The example above works, because our default user class path
happens to be the directory containing the package directory. But
suppose we want to recompile this file and not worry about which
directory we're in? Then we need to add /examples to the
user class path. We can do this by setting CLASSPATH, but here
we'll use the -classpath option.
It often makes sense to keep source files and class files in separate
directories, especially on large projects. We use -d to indicate
the separate class file destination. Since the source files are not in
the user class path, we use -sourcepath to help the compiler
find them.
% ls
classes/ lib/ src/
% ls src
farewells/
% ls src/farewells
Base.java GoodBye.java
% ls lib
Banners.jar
% ls classes
% javac -sourcepath src -classpath classes:lib/Banners.jar \
src/farewells/GoodBye.java -d classes
% ls classes
farewells/
% ls classes/farewells
Base.class GoodBye.class
Note that the compiler compiled src/farewells/Base.java,
even though we didn't specify it on the command line. To trace
automatic compiles, use the -verbose option.
The -target 1.1 option ensures that the generated class files will
be compatible with 1.1 VMs. In the Java 2 SDK javac compiles for 1.1 by
default, so this option is not strictly required. However, it is good
form because other compilers may have other defaults.
The Java 2 SDK's javac would also by default compile against its own
bootstrap classes, so we need to tell javac to compile against
JDK 1.1 bootstrap classes instead. We do this with -bootclasspath
and -extdirs. Failing to do this might allow compilation against a
Java 2 Platform API that would not be present on a 1.1 VM and fail at runtime.