Provided by: gcj-5-alpha-linux-gnu_5.3.1-14ubuntu2cross1_amd64 bug

NAME

       gcj - Ahead-of-time compiler for the Java language

SYNOPSIS

       gcj [-Idir...] [-d dir...]
           [--CLASSPATH=path] [--classpath=path]
           [-foption...] [--encoding=name]
           [--main=classname] [-Dname[=value]...]
           [-C] [--resource resource-name] [-d directory]
           [-Wwarn...]
           sourcefile...

DESCRIPTION

       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.

OPTIONS

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

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

   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 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 "-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 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).  This does not override the builtin
           ("boot") search path.

       --CLASSPATH=path
           Deprecated synonym for "--classpath".

       --bootclasspath=path
           Where to find the standard builtin classes, such as "java.lang.String".

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

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

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

       -fsource=VERSION
           This option is used to choose the source version accepted by gcj.  The default is 1.5.

   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.

       -Wno-deprecated
           Warn if a deprecated class, method, or field is referred to.

       -Wunused
           This is the same as gcc's "-Wunused".

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

   Linking
       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, described below.

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

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

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

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

       -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 "ClassNotFoundException" being thrown at runtime.
           Caution must be used when using this option.  For more details see:
           <http://gcc.gnu.org/wiki/Statically%20linking%20libgcj>

   Code Generation
       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 "ResourceBundle.getBundle".  The actual file
           name to be compiled this way must be specified separately.

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

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

       -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-assert
           Don't recognize the "assert" keyword.  This is for compatibility with older versions
           of the language specification.

       -fno-optimize-static-class-initialization
           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.

       --disable-assertions[=class-or-package]
           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.

       --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
           "--disable-assertions".

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

       -fbootstrap-classes
           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 desired class.

       -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 "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 with "-freduced-reflection".

           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 reflection meta-data.

   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.

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

SEE ALSO

       gcc(1), gcjh(1), gjnih(1), gij(1), jcf-dump(1), gfdl(7), and the Info entries for gcj and
       gcc.

COPYRIGHT

       Copyright (c) 2001-2015 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.