Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

RedHat 9 (Linux i386) - man page for gcj (redhat section 1)

GCJ(1)					       GNU					   GCJ(1)

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

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

       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.

       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 ar-
	   chive may be compressed.

	   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 com-
       piled 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 sev-
       eral 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.

	   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 manipu-
	   lating 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 "java.lang.String".

	   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:

       o   First come all directories specified via "-I".

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

       o   If "--bootclasspath" was specified, append its value.  Otherwise, append the built-in
	   system directory, libgcj.jar.

       o   Finaly, 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.)

	   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.


       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 inter-
       nally, 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 oppo-
       site of what is listed.

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

	   This causes gcj to warn about empty statements.  Empty statements have been depre-

	   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.

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

	   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.

	   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]

	   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

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

       -d directory
	   When used with "-C", this causes all generated .class files to be put in the appropri-
	   ate subdirectory of directory.  By default they will be put in subdirectories of the
	   current working directory.

	   By default, gcj generates code which checks the bounds of all array indexing opera-
	   tions.  With this option, these checks are omitted, which can improve performance for
	   code that uses arrays extensively.  Note that this can result in unpredictable behav-
	   ior 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 "ArrayIn-

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

	   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.

	   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 meaning-
       fully given when "libgcj", the runtime package, is configured.  "libgcj" puts the appro-
       priate 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

	   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.

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

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

       Copyright (C) 2001, 2002 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 man page gfdl(7).

gcc-3.2.2				    2003-02-25					   GCJ(1)

All times are GMT -4. The time now is 04:10 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password