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