gcj(1)


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





Opportunity


Personal Opportunity - Free software gives you access to billions of dollars of software at no cost. Use this software for your business, personal use or to develop a profitable skill. Access to source code provides access to a level of capabilities/information that companies protect though copyrights. Open source is a core component of the Internet and it is available to you. Leverage the billions of dollars in resources and capabilities to build a career, establish a business or change the world. The potential is endless for those who understand the opportunity.

Business Opportunity - Goldman Sachs, IBM and countless large corporations are leveraging open source to reduce costs, develop products and increase their bottom lines. Learn what these companies know about open source and how open source can give you the advantage.





Free Software


Free Software provides computer programs and capabilities at no cost but more importantly, it provides the freedom to run, edit, contribute to, and share the software. The importance of free software is a matter of access, not price. Software at no cost is a benefit but ownership rights to the software and source code is far more significant.


Free Office Software - The Libre Office suite provides top desktop productivity tools for free. This includes, a word processor, spreadsheet, presentation engine, drawing and flowcharting, database and math applications. Libre Office is available for Linux or Windows.





Free Books


The Free Books Library is a collection of thousands of the most popular public domain books in an online readable format. The collection includes great classical literature and more recent works where the U.S. copyright has expired. These books are yours to read and use without restrictions.


Source Code - Want to change a program or know how it works? Open Source provides the source code for its programs so that anyone can use, modify or learn how to write those programs themselves. Visit the GNU source code repositories to download the source.





Education


Study at Harvard, Stanford or MIT - Open edX provides free online courses from Harvard, MIT, Columbia, UC Berkeley and other top Universities. Hundreds of courses for almost all major subjects and course levels. Open edx also offers some paid courses and selected certifications.


Linux Manual Pages - A man or manual page is a form of software documentation found on Linux/Unix operating systems. Topics covered include computer programs (including library and system calls), formal standards and conventions, and even abstract concepts.