java [ Java options ] JavaCodeCompact [ options ] filename ...
JavaCodeCompact combines one or more Java class files and produces a target-system dependent C file that contains the given classes in a preloaded format that can be compiled and linked with the Java virtual machine.
Here is an outline of the conventional mechanism for class loading:
JavaCodeCompact provides an alternate means of program linking and symbol resolution, one that provides a less-flexible model of program building, but which helps reduce the VM's bandwidth and memory requirements.
JavaCodeCompact can:
This program often has to be run with an increased maximum heap size. -mx20m increases the heap to 20MB.
.c
for C language output,
but this is not important to the operation of the program.
In the absence of this option, a file is produced with a name based
on that of the first input file, stripped of pathname prefix and any suffix,
to which a suffix is appended.
If the -q option is given, the
suffix is ".c", otherwise
".mclass" is used.
JavaCodeCompact
determines the offset of every instance variable
and the methodtable offset of each non-static method for each class
in the generated file.
It requires that the complete inheretance hierarchy for each class
be present in the set of classes linked.
Many Java bytecode instructions refer to symbolic quantities such as the offset of a field or of a method, or simply to the name of a type. Normally, the Java Virtual Machine resolves these referenced upon first executing the instructions, and re-writes the instruction in place. This yields non-ROMable code. Java bytecodes resolved and quickened at link time are read-only and thus ROMable. Instructions referring to symbols not resolved remain un-quick, and thus writable.
This option should only be used on the ultimate link step.
JavaCodeCompact
uses to look up classes.
Directories and Zip files are separated by the delimeter defined by
java.io.File.pathSeparatorChar
,
which is generally a colon.
Multiple classpath options are cumulative, and are searched left-to-right.
This option is only used in conjunction with the -c cumulative-linking option,
as well as the -memberlist selective-linking option.
javah
for all the classes read as input. Files are written in
the indicated target directory. Header files unchanged
remain untouched.
This option should only be used on the ultimate link step.
javah -stubs
,
for all native (but non-JNI) methods in the classes read as input. The stubs
file is written to the indicated filename.
This option should only be used on the ultimate link step.
-headers
option is
given. JNI headers must be generated using javah -jni
.
If the last component of the classname
is *
, then its prefix is treated as
a package, all classes of which use JNI linkage. Thus,
for instance,
-jniClass java.lang.*
would specify JNI linkage for all the native methods of
all the
classes in the java.lang
package.
Performs selective loading as directed by the indicated file. This file is an ASCII file, as produced by JavaFilter, containing the names of classes and class members. The file is read, and the named class members are sought along the path indicated by the -classpath directive. Of the classes loaded in this manner, only the named members will be included in the output -- any other members will be discarded.
N.B.: Classes loaded by the combination of -memberlist and -classpath are loaded selectivly. Class files named directly on the command line are loaded entirely.
The Java Virtual Machine Specification by Lindholm and Yellin. Addison Wesley, 1996.