In addition to the many gcc options controlling code generation, gcj has several options specific to itself.
ResourceBundle.getBundle. The actual file name to be compiled this way must be specified separately.
-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.
-fjni. This option causes gcj to generate stubs which will invoke the underlying JNI methods.
assertkeyword. This is for compatibility with older versions of the language specification.
-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
-Cwas specified.) When compiling to native code,
-fno-optimize-static-class-initializationwill turn this optimization off, regardless of the optimization level in use.
=class-or-package is missing disables assertion code generation for all classes, unless overridden by a more specific
--enable-assertionsflag. 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.
-findirect-dispatchoption. 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.
libgcjthat 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.
For code that does not use reflection (i.e. serialization, RMI, CORBA
or call methods in the
-freduced-reflection will result in proper operation with a
savings in executable code size.
-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
Caution: If there is no reflection meta-data, code that uses
SecurityManager may not work properly. Also calling
Class.forName() may fail if the calling method has no