\input texinfo

Copyright (C) 2001 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.1 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 section entitled ``GNU Free Documentation License''.

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

Introduction
************

This manual describes how to use gcj, the GNU compiler for the Java programming language.  gcj can generate both .class files and object files, and it can read both Java source code and .class files.

     [file gpl.texi not included]

     [file fdl.texi not included]

Invoking gcj
************

As gcj is just another front end to gcc, it supports many of the same options as gcc.  See Option Summary (Using the GNU Compiler Collection (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:

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 or -R. (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.)

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

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.

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.

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

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

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

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

-fno-optimize-static-class-initialization
     When the optimization level is greather 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.

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.

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

Compatibility with the Java Platform
************************************

As we believe it is important that the Java platform not be fragmented, gcj and libgcj try to conform to the relevant Java specifications.  However, limited manpower and incomplete and unclear documentation work against us.  So, there are caveats to using gcj.

This list of compatibility issues is by no means complete.

  * gcj implements the JDK 1.1 language.  It supports inner classes, though these are known to still be buggy.  It does not yet support the Java 2 strictfp keyword (it recognizes the keyword but ignores it).

  * libgcj is largely compatible with the JDK 1.2 libraries. However, libgcj is missing many packages, most notably java.awt.  There are also individual missing classes and methods. We currently do not have a list showing differences between libgcj and the Java 2 platform.

  * Sometimes the libgcj implementation of a method or class differs from the JDK implementation.  This is not always a bug.  Still, if it affects you, it probably makes sense to report it so that we can discuss the appropriate response.

Invoking gcjh
*************

The gcjh program is used to generate header files from class files.  It can generate both CNI and JNI header files, as well as stub implementation files which can be used as a basis for implementing the required native methods.

-stubs
     This causes gcjh to generate stub files instead of header files. By default the stub file will be named after the class, with a suffix of .cc.  In JNI mode, the default output file will have the suffix .c.

-jni
     This tells gcjh to generate a JNI header or stub.  By default, CNI headers are generated.

-add TEXT
     Inserts TEXT into the class body.  This is ignored in JNI mode.

-append TEXT
     Inserts TEXT into the header file after the class declaration. This is ignored in JNI mode.

-friend TEXT
     Inserts TEXT into the class as a friend declaration. This is ignored in JNI mode.

-prepend TEXT
     Inserts TEXT into the header file before the class declaration. This is ignored in JNI mode.

--classpath=PATH
--CLASSPATH=PATH
-IDIRECTORY
-d DIRECTORY
-o FILE
     These options are all identical to the corresponding gcj options.

-o FILE
     Sets the output file name.  This cannot be used if there is more than one class on the command line.

-td DIRECTORY
     Sets the name of the directory to use for temporary files.

-M
     Print all dependencies to stdout; suppress ordinary output.

-MM
     Print non-system dependencies to stdout; suppress ordinary output.

-MD
     Print all dependencies to stdout.

-MMD
     Print non-system dependencies to stdout.

--help
     Print help about gcjh and exit.  No further processing is done.

--version
     Print version information for gcjh and exit.  No further processing is done.

-v, --verbose
     Print extra information while running.

All remaining options are considered to be names of classes.

Invoking jv-scan
****************

The jv-scan program can be used to print information about a Java source file (.java file).

--complexity
     This prints a complexity measure, related to cyclomatic complexity, for each input file.

--encoding=NAME
     This works like the corresponding gcj option.

--print-main
     This prints the name of the class in this file containing a main method.

--list-class
     This lists the names of all classes defined in the input files.

--list-filename
     If --list-class is given, this option causes jv-scan to also print the name of the file in which each class was found.

-o FILE
     Print output to the named file.

--help
     Print help, then exit.

--version
     Print version number, then exit.

Invoking jcf-dump
*****************

This is a class file examiner, similar to javap.  It will print information about a number of classes, which are specifed by class name or file name.

-c
     Disassemble method bodies.  By default method bodies are not printed.

--javap
     Generate output in javap format.  The implementation of this feature is very incomplete.

--classpath=PATH
--CLASSPATH=PATH
-IDIRECTORY
-o FILE
     These options as the same as the corresponding gcj options.

--help
     Print help, then exit.

--version
     Print version number, then exit.

-v, --verbose
     Print extra information while running.

Invoking gij
************

gij is a Java bytecode interpreter included with libgcj. gij is not available on every platform; porting it requires a small amount of assembly programming which has not been done for all the targets supported by gcj.

The primary argument to gij is the name of a class or, with -jar, a jar file.  Options before this argument are interpreted by gij; remaining options are passed to the interpreted program.

If a class name is specified and this class does not have a main method with the appropriate signature (a static void method with a String[] as its sole argument), then gij will print an error and exit.

If a jar file is specified then gij will use information in it to determine which class' main method will be invoked.

gij will invoke the main method with all the remaining command-line options.

Note that gij is not limited to interpreting code.  Because libgcj includes a class loader which can dynamically load shared objects, it is possible to give gij the name of a class which has been compiled and put into a shared library on the class path.

-DNAME[=VALUE]
     This 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.

-ms=NUMBER
     This sets the initial heap size.

-mx=NUMBER
     This sets the maximum heap size.

-jar
     This indicates that the name passed to gij should be interpreted as the name of a jar file, not a class.

--help
     Print help, then exit.

--version
     Print version number, then exit.

Resources
*********

While writing gcj and libgcj we have, of course, relied heavily on documentation from Sun Microsystems.  In particular we have used The Java Language Specification (both first and second editions), the Java Class Libraries (volumes one and two), and the Java Virtual Machine Specification.  In addition we've used the online documentation at http://java.sun.com/.

The current gcj home page is http://gcc.gnu.org/java/.

For more information on gcc, see http://gcc.gnu.org/.

Some libgcj testing is done using the Mauve test suite.  This is a free software Java class library test suite which is being written because the JCK is not free.  See http://sources.redhat.com/mauve/ for more information.