gcj man page on YellowDog

Man page or keyword search:  
man Server   18644 pages
apropos Keyword Search (all sections)
Output format
YellowDog logo
[printable version]

GCJ(1)				      GNU				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 sin‐
       gle output file, named FILENAME.	 This is allowed even when using "-S"
       or "-c", but not when using "-C" or "--resource".  (This is an exten‐
       sion 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 lan‐
       guage, 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 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 direc‐
	   tory 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 "$(pre‐
	   fix)/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-ar‐
       chive-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.

       -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 appli‐
       cation.	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 config‐
	   uring 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 run‐
	   time 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 cor‐
	   responding 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%20link‐
	   ing%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.

       -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 exten‐
	   sively.  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 compil‐
	   ing 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 initial‐
	   ize 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 opti‐
	   mization 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 genera‐
	   tion 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 subpack‐
	   age.

	   By default, assertions are enabled when generating class files or
	   when not optimizing, and disabled when generating optimized bina‐
	   ries.

       --enable-assertions[=class-or-package]
	   Generates code to check assertions.	The option is perhaps mis‐
	   named, 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-asser‐
	   tions".

       -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 dependen‐
	   cies are looked up at runtime.  This allows free mixing of inter‐
	   preted 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. the 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-dis‐
	   patch") do not work properly without full reflection meta-data.
	   Because of this, it is an error to use these options with "-fre‐
	   duced-reflection".

	   Caution: If there is no reflection meta-data, code that uses a
	   "SecurityManager" may not work properly.  Also calling "Class.for‐
	   Name()" 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 con‐
       figured.	 "libgcj" puts the appropriate options from this group into a
       spec file which is read by gcj.	These options are listed here for com‐
       pleteness; 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 par‐
	   ticular 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.

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

COPYRIGHT
       Copyright (c) 2001, 2002, 2003, 2004, 2005 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.2 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).

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

gcc-4.1.2			  2009-05-05				GCJ(1)
[top]

List of man pages available for YellowDog

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net