1. Invoking gcj

As gcj is just another front end to gcc, it supports many of the same options as gcc. See section `Option Summary' in Using the GNU Compiler Collection. This manual only documents the options specific to gcj.

1.1 Input and output files
1.2 Input Options		How gcj finds files
1.3 Encodings		Options controlling source file encoding
1.4 Warnings		Options controlling warnings specific to gcj
1.5 Code Generation		Options controlling the output of gcj
1.6 Configure-time Options		Options you won't use

1.1 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:

file.java

Java source files.

file.class

Java bytecode files.

file.zip

file.jar

An archive containing one or more .class files, all of which are compiled. The archive may be compressed.

@file

A file containing a whitespace-separated list of input file names. (Currently, these must all be .java source files, but that may change.) Each named file is compiled, just as if it had been on the command line.

library.a

library.so

-llibname

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 -o FILENAME 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. (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.)

1.2 Input Options

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.

In the 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 -I are kept in order and prepended to the class path constructed from all the other options. Unless compatibility with tools like javac is imported, we recommend always using -I instead of the other options for manipulating the class path.

--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).

--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 differs from the --classpath option in that it also suppresses the built-in system path.

CLASSPATH

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 and processing stops. That is, --classpath suppresses all the options mentioned later in this list.

• If --CLASSPATH is specified, its value is appended and the CLASSPATH environment variable is suppressed.

• If the CLASSPATH environment variable is specified (and was not suppressed by --CLASSPATH), then its value is appended.

• Finally, the built-in system directory, `libgcj.jar', is appended.

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 overide this behavior in this particular case.)

-fforce-classes-archive-check

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.

1.3 Encodings

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 of Unicode.

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.

1.4 Warnings

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.

-Wredundant-modifiers

With this flag, gcj will warn about redundant modifiers. For instance, it will warn if an interface method is declared public.

-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.

-Wunused

This is the same as gcc's -Wunused.

-Wall

This is the same as -Wredundant-modifiers -Wextraneous-semicolon -Wunused.

1.5 Code Generation

In addition to the many gcc options controlling code generation, gcj has several options specific to itself.

--main=CLASSNAME

This option is used when linking to specify the name of the class whose main method should be invoked when the resulting executable is run. (1)

-Dname[=value]

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.

-C

This option is used to tell gcj to generate bytecode (`.class' files) rather than object code.

-d directory

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 directory.

-fno-bounds-check

By default, gcj generates code which checks the bounds of all array indexing operations. With this option, these checks are omitted. Note that this can result in unpredictable behavior if the code in question actually does violate array bounds constraints.

-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 -fjni. This option causes gcj to generate stubs which will invoke the underlying JNI methods.

1.6 Configure-time Options

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.

-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 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.

-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.