The main feature of gcj is that it can compile programs written in the Java programming language to native code. Most extensions that have been added are to facilitate this functionality.
-findirect-dispatchthen add them to the system-wide classmap.db file using
gcj-dbtool, they will be automatically loaded by the
libgcjsystem classloader. This is the new, preferred classname-to-library resolution mechanism. See Invoking gcj-dbtool, for more information on using the classmap database.
gnu.gcj.runtime.VMClassLoader.library_controlproperty, but it is deprecated and will likely be removed in some future release. When trying to load a class
gnu.pkg.SomeClassthe system classloader will first try to load the shared library lib-gnu-pkg-SomeClass.so, if that fails to load the class then it will try to load lib-gnu-pkg.so and finally when the class is still not loaded it will try to load lib-gnu.so. Note that all `.'s will be transformed into `-'s and that searching for inner classes starts with their outermost outer class. If the class cannot be found this way the system classloader tries to use the
libgcjbytecode interpreter to load the class from the standard classpath. This process can be controlled to some degree via the
gnu.gcj.runtime.VMClassLoader.library_controlproperty; See libgcj Runtime Properties.
libgcjincludes a special `gcjlib' URL type. A URL of this form is like a
jarURL, and looks like `gcjlib:/path/to/shared/library.so!/path/to/resource'. An access to one of these URLs causes the shared library to be
dlopen()d, and then the resource is looked for in that library. These URLs are most useful when used in conjunction with
java.net.URLClassLoader. Note that, due to implementation limitations, currently any such URL can be accessed by only one class loader, and libraries are never unloaded. This means some care must be exercised to make sure that a
gcjlibURL is not accessed by more than one class loader at once. In a future release this limitation will be lifted, and such libraries will be mapped privately.