As gcj is just another front end to gcc, it supports many
of the same options as gcc. This manual only documents the
options specific to gcj.
Input and output files
A gcj command is like a gcc command, in that it
consists of a number of options and file names. The following kinds
of input file names are supported:
Java source files.
Java bytecode files.
An archive containing one or more ".class" files, all of
which are compiled. The archive may be compressed. Files in
an archive which don't end with .class are treated as
resource files; they are compiled into the resulting object file
as core: URLs.
A file containing a whitespace-separated list of input file names.
(Currently, these must all be ".java" source files, but that
Each named file is compiled, just as if it had been on the command line.
Libraries to use when linking. See the gcc manual.
You can specify more than one input file on the gcj command line,
in which case they will all be compiled. If you specify a
option, all the input files will be compiled together, producing a
single output file, named FILENAME.
This is allowed even when using "-S" or "-c",
but not when using "-C" or "--resource".
(This is an extension beyond the what plain gcc allows.)
(If more than one input file is specified, all must currently
be ".java" files, though we hope to fix this.)
gcj has options to control where it looks to find files it needs.
For instance, gcj might need to load a class that is referenced
by the file it has been asked to compile. Like other compilers for the
Java language, gcj has a notion of a class path. There are
several options and environment variables which can be used to
manipulate the class path. When gcj looks for a given class, it
searches the class path looking for matching .class or
.java file. gcj comes with a built-in class path which
points at the installed libgcj.jar, a file which contains all the
In the text below, a directory or path component can refer either to an
actual directory on the filesystem, or to a .zip or .jar
file, which gcj will search as if it is a directory.
All directories specified by "-I" are kept in order and prepended
to the class path constructed from all the other options. Unless
compatibility with tools like "javac" is important, we recommend
always using "-I" instead of the other options for manipulating the
This sets the class path to path, a colon-separated list of paths
(on Windows-based systems, a semicolon-separate list of paths).
This does not override the builtin (``boot'') search path.
Deprecated synonym for "--classpath".
Where to find the standard builtin classes, such as "java.lang.String".
For each directory in the path, place the contents of that
directory at the end of the class path.
This is an environment variable which holds a list of paths.
The final class path is constructed like so:
First come all directories specified via "-I".
If --classpath is specified, its value is appended.
Otherwise, if the "CLASSPATH" environment variable is specified,
then its value is appended.
Otherwise, the current directory (".") is appended.
If "--bootclasspath" was specified, append its value.
Otherwise, append the built-in system directory, libgcj.jar.
Finally, if "--extdirs" was specified, append the contents of the
specified directories at the end of the class path. Otherwise, append
the contents of the built-in extdirs at "$(prefix)/share/java/ext".
The classfile built by gcj for the class "java.lang.Object"
(and placed in "libgcj.jar") contains a special zero length
attribute "gnu.gcj.gcj-compiled". The compiler looks for this
attribute when loading "java.lang.Object" and will report an error
if it isn't found, unless it compiles to bytecode (the option
"-fforce-classes-archive-check" can be used to override this
behavior in this particular case.)
This forces the compiler to always check for the special zero length
attribute "gnu.gcj.gcj-compiled" in "java.lang.Object" and
issue an error if it isn't found.
This option is used to choose the source version accepted by
gcj. The default is 1.5.
The Java programming language uses Unicode throughout. In an effort to
integrate well with other locales, gcj allows .java files
to be written using almost any encoding. gcj knows how to
convert these encodings into its internal encoding at compile time.
You can use the "--encoding=NAME" option to specify an
encoding (of a particular character set) to use for source files. If
this is not specified, the default encoding comes from your current
locale. If your host system has insufficient locale support, then
gcj assumes the default encoding to be the UTF-8 encoding
To implement "--encoding", gcj simply uses the host
platform's "iconv" conversion routine. This means that in practice
gcj is limited by the capabilities of the host platform.
The names allowed for the argument "--encoding" vary from platform
to platform (since they are not standardized anywhere). However,
gcj implements the encoding named UTF-8 internally, so if
you choose to use this for your source files you can be assured that it
will work on every host.
gcj implements several warnings. As with other generic
gcc warnings, if an option of the form "-Wfoo" enables a
warning, then "-Wno-foo" will disable it. Here we've chosen to
document the form of the warning which will have an effect --- the
default being the opposite of what is listed.
With this flag, gcj will warn about redundant modifiers. For
instance, it will warn if an interface method is declared "public".
This causes gcj to warn about empty statements. Empty statements
have been deprecated.
This option will cause gcj not to warn when a source file is
newer than its matching class file. By default gcj will warn
Warn if a deprecated class, method, or field is referred to.
This is the same as gcc's "-Wunused".
This is the same as "-Wredundant-modifiers -Wextraneous-semicolon
To turn a Java application into an executable program,
you need to link it with the needed libraries, just as for C or C++.
The linker by default looks for a global function named "main".
Since Java does not have global functions, and a
collection of Java classes may have more than one class with a
"main" method, you need to let the linker know which of those
"main" methods it should invoke when starting the application.
You can do that in any of these ways:
Specify the class containing the desired "main" method
when you link the application, using the "--main" flag,
Link the Java package(s) into a shared library (dll) rather than an
executable. Then invoke the application using the "gij" program,
making sure that "gij" can find the libraries it needs.
Link the Java packages(s) with the flag "-lgij", which links
in the "main" routine from the "gij" command.
This allows you to select the class whose "main" method you
want to run when you run the application. You can also use
other "gij" flags, such as "-D" flags to set properties.
Using the "-lgij" library (rather than the "gij" program
of the previous mechanism) has some advantages: it is compatible with
static linking, and does not require configuring or installing libraries.
These "gij" options relate to linking an executable:
This option is used when linking to specify the name of the class whose
"main" method should be invoked when the resulting executable is
This option can only be used with "--main". It defines a system
property named name with value value. If value is not
specified then it defaults to the empty string. These system properties
are initialized at the program's startup and can be retrieved at runtime
using the "java.lang.System.getProperty" method.
Create an application whose command-line processing is that
of the "gij" command.
This option is an alternative to using "--main"; you cannot use both.
This option causes linking to be done against a static version of the
libgcj runtime library. This option is only available if
corresponding linker support exists.
Caution: Static linking of libgcj may cause essential parts
of libgcj to be omitted. Some parts of libgcj use reflection to load
classes at runtime. Since the linker does not see these references at
link time, it can omit the referred to classes. The result is usually
(but not always) a "ClassNotFoundException" being thrown at
runtime. Caution must be used when using this option. For more
In addition to the many gcc options controlling code generation,
gcj has several options specific to itself.
This option is used to tell gcj to generate bytecode
(.class files) rather than object code.
This option is used to tell gcj to compile the contents of a
given file to object code so it may be accessed at runtime with the core
protocol handler as core:/resource-name. Note that
resource-name is the name of the resource as found at runtime; for
instance, it could be used in a call to "ResourceBundle.getBundle".
The actual file name to be compiled this way must be specified
This can be used with -C to choose the version of bytecode
emitted by gcj. The default is 1.5. When not
generating bytecode, this option has no effect.
When used with "-C", this causes all generated .class files
to be put in the appropriate subdirectory of directory. By
default they will be put in subdirectories of the current working
By default, gcj generates code which checks the bounds of all
array indexing operations. With this option, these checks are omitted, which
can improve performance for code that uses arrays extensively. Note that this
can result in unpredictable behavior if the code in question actually does
violate array bounds constraints. It is safe to use this option if you are
sure that your code will never throw an "ArrayIndexOutOfBoundsException".
Don't generate array store checks. When storing objects into arrays, a runtime
check is normally generated in order to ensure that the object is assignment
compatible with the component type of the array (which may not be known
at compile-time). With this option, these checks are omitted. This can
improve performance for code which stores objects into arrays frequently.
It is safe to use this option if you are sure your code will never throw an
With gcj there are two options for writing native methods: CNI
and JNI. By default gcj assumes you are using CNI. If you are
compiling a class with native methods, and these methods are implemented
using JNI, then you must use "-fjni". This option causes
gcj to generate stubs which will invoke the underlying JNI
Don't recognize the "assert" keyword. This is for compatibility
with older versions of the language specification.
When the optimization level is greater or equal to "-O2",
gcj will try to optimize the way calls into the runtime are made
to initialize static classes upon their first use (this optimization
isn't carried out if "-C" was specified.) When compiling to native
code, "-fno-optimize-static-class-initialization" will turn this
optimization off, regardless of the optimization level in use.
Don't include code for checking assertions in the compiled code.
If "=class-or-package" is missing disables assertion code
generation for all classes, unless overridden by a more
specific "--enable-assertions" flag.
If class-or-package is a class name, only disables generating
assertion checks within the named class or its inner classes.
If class-or-package is a package name, disables generating
assertion checks within the named package or a subpackage.
By default, assertions are enabled when generating class files
or when not optimizing, and disabled when generating optimized binaries.
Generates code to check assertions. The option is perhaps misnamed,
as you still need to turn on assertion checking at run-time,
and we don't support any easy way to do that.
So this flag isn't very useful yet, except to partially override
gcj has a special binary compatibility ABI, which is enabled
by the "-findirect-dispatch" option. In this mode, the code
generated by gcj honors the binary compatibility guarantees
in the Java Language Specification, and the resulting object files do
not need to be directly linked against their dependencies. Instead,
all dependencies are looked up at runtime. This allows free mixing of
interpreted and compiled code.
Note that, at present, "-findirect-dispatch" can only be used
when compiling .class files. It will not work when compiling
from source. CNI also does not yet work with the binary compatibility
ABI. These restrictions will be lifted in some future release.
However, if you compile CNI code with the standard ABI, you can call
it from code built with the binary compatibility ABI.
This option can be use to tell "libgcj" that the compiled classes
should be loaded by the bootstrap loader, not the system class loader.
By default, if you compile a class and link it into an executable, it
will be treated as if it was loaded using the system class loader.
This is convenient, as it means that things like
"Class.forName()" will search CLASSPATH to find the
This option causes the code generated by gcj to contain a
reduced amount of the class meta-data used to support runtime
reflection. The cost of this savings is the loss of
the ability to use certain reflection capabilities of the standard
Java runtime environment. When set all meta-data except for that
which is needed to obtain correct runtime semantics is eliminated.
For code that does not use reflection (i.e. the methods in the
"java.lang.reflect" package), "-freduced-reflection"
will result in proper operation with a savings in executable code size.
JNI ("-fjni") and the binary compatibility ABI
("-findirect-dispatch") do not work properly without full
reflection meta-data. Because of this, it is an error to use these options
Caution: If there is no reflection meta-data, code that uses
a "SecurityManager" may not work properly. Also calling
"Class.forName()" may fail if the calling method has no
Some gcj code generations options affect the resulting ABI, and
so can only be meaningfully given when "libgcj", the runtime
package, is configured. "libgcj" puts the appropriate options from
this group into a spec file which is read by gcj. These
options are listed here for completeness; if you are using "libgcj"
then you won't want to touch these options.
This enables the use of the Boehm GC bitmap marking code. In particular
this causes gcj to put an object marking descriptor into each
By default, synchronization data (the data used for "synchronize",
"wait", and "notify") is pointed to by a word in each object.
With this option gcj assumes that this information is stored in a
hash table and not in the object itself.
On some systems, a library routine is called to perform integer
division. This is required to get exception handling correct when
dividing by zero.
On some systems it's necessary to insert inline checks whenever
accessing an object via a reference. On other systems you won't need
this because null pointer accesses are caught automatically by the
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with the
Invariant Sections being ``GNU General Public License'', the Front-Cover
texts being (a) (see below), and with the Back-Cover Texts being (b)
(see below). A copy of the license is included in the
man page gfdl(7).
(a) The FSF's Front-Cover Text is:
A GNU Manual
(b) The FSF's Back-Cover Text is:
You have freedom to copy and modify this GNU Manual, like GNU
software. Copies published by the Free Software Foundation raise
funds for GNU development.