gcj - Ahead-of-time compiler for the Java language
gcj [-Idir...] [-d dir...]
[-C] [--resource resource-name] [-d directory]
[-C] [--resource resource-name] [-d directory]
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:
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
|file.java||Java source files.|
|file.class||Java bytecode files.|
|file.jar||An archive containing one or more
|@file||A file containing a whitespace-separated list of input file names. (Currently, these must all be
|-llibname||Libraries to use when linking. See the gcc manual.|
FILENAMEoption, all the input files will be compiled together, producing a single output file, named FILENAME. This is allowed even when using
-c, but not when using
--resource. (This is an extension beyond the what plain gcc allows.) (If more than one input file is specified, all must currently be
.javafiles, 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 standard classes.
The final class path is constructed like so:
The classfile built by gcj for the class
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.
|-Idir||All directories specified by
|--classpath=path||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.|
|--CLASSPATH=path||Deprecated synonym for
|--bootclasspath=path||Where to find the standard builtin classes, such as
|--extdirs=path||For each directory in the path, place the contents of that directory at the end of the class path.|
|CLASSPATH||This is an environment variable which holds a list of paths.|
|*||First come all directories specified via
|*||If --classpath is specified, its value is appended. Otherwise, if the
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.Objectand will report an error if it isn’t found, unless it compiles to bytecode (the option
-fforce-classes-archive-checkcan be used to override this behavior in this particular case.)
|-fforce-classes-archive-check||This forces the compiler to always check for the special zero length attribute
|-fsource=VERSION||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
NAMEoption 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 of Unicode.
--encoding, gcj simply uses the host platform’s
iconvconversion routine. This means that in practice gcj is limited by the capabilities of the host platform.
The names allowed for the argument
--encodingvary 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
-Wfooenables a warning, then
-Wno-foowill 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.
|-Wredundant-modifiers||With this flag, gcj will warn about redundant modifiers. For instance, it will warn if an interface method is declared
|-Wextraneous-semicolon||This causes gcj to warn about empty statements. Empty statements have been deprecated.|
|-Wno-out-of-date||This option will cause gcj not to warn when a source file is newer than its matching class file. By default gcj will warn about this.|
|-Wno-deprecated||Warn if a deprecated class, method, or field is referred to.|
|-Wunused||This is the same as gcc’s
|-Wall||This is the same as
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
mainmethod, you need to let the linker know which of those
mainmethods it should invoke when starting the application. You can do that in any of these ways:
|*||Specify the class containing the desired
|*||Link the Java package(s) into a shared library (dll) rather than an executable. Then invoke the application using the
|*||Link the Java packages(s) with the flag
gijoptions relate to linking an executable:
|--main=CLASSNAME||This option is used when linking to specify the name of the class whose
|-Dname[=value]||This option can only be used with
|-lgij||Create an application whose command-line processing is that of the
This option is an alternative to using
|-static-libgcj||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
In addition to the many gcc options controlling code generation, gcj has several options specific to itself.
|-C||This option is used to tell gcj to generate bytecode (.class files) rather than object code.|
|--resource resource-name||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
|-ftarget=VERSION||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.|
|-d directory||When used with
|-fno-bounds-check||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
|-fno-store-check||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
|-fjni||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
|-fno-assert||Don’t recognize the
|-fno-optimize-static-class-initialization||When the optimization level is greater or equal to
|--disable-assertions[=class-or-package]||Don’t include code for checking assertions in the compiled code. If
By default, assertions are enabled when generating class files or when not optimizing, and disabled when generating optimized binaries.
|--enable-assertions[=class-or-package]||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
|-findirect-dispatch||gcj has a special binary compatibility ABI, which is enabled by the
Note that, at present,
However, if you compile CNI code with the standard ABI, you can call it from code built with the binary compatibility ABI.
|-fbootstrap-classes||This option can be use to tell
|-freduced-reflection||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. serialization, RMI, CORBA or call methods in the
Caution: If there is no reflection meta-data, code that uses a
Some gcj code generations options affect the resulting ABI, and so can only be meaningfully given when
libgcj, the runtime package, is configured.
libgcjputs 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
libgcjthen you won’t want to touch these options.
|-fuse-boehm-gc||This enables the use of the Boehm GC bitmap marking code. In particular this causes gcj to put an object marking descriptor into each vtable.|
|-fhash-synchronization||By default, synchronization data (the data used for
|-fuse-divide-subroutine||On some systems, a library routine is called to perform integer division. This is required to get exception handling correct when dividing by zero.|
|-fcheck-references||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 processor.|
|-fuse-atomic-builtins||On some systems, GCC can generate code for built-in atomic operations. Use this option to force gcj to use these builtins when compiling Java code. Where this capability is present it should be automatically detected, so you won’t usually need to use this option.|
Copyright (c) 2001-2016 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, 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.