GCJ(1)                               GNU                              GCJ(1)

NAME         top

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

SYNOPSIS         top

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

DESCRIPTION         top

       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

OPTIONS         top

   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:

           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.

           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.

           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.

           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

           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

       *   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

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

       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

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

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

           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.

           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

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

   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.

           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

           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

           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 desired

           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.

           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.

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

           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         top

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

COPYRIGHT         top

       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.

COLOPHON         top

       This page is part of the gcc (GNU Compiler Collection) project.
       Information about the project can be found at ⟨⟩.
       If you have a bug report for this manual page, see 
       ⟨⟩.  This page was obtained from the tarball
       gcc-6.3.0.tar.gz fetched from 
       ⟨⟩ on 2017-04-25.
       If you discover any rendering problems in this HTML version of the
       page, or you believe there is a better or more up-to-date source for
       the page, or you have corrections or improvements to the information
       in this COLOPHON (which is not part of the original manual page),
       send a mail to

gcc-6.3.0                        2016-12-21                           GCJ(1)