For your operating system to know where to find the executable binary files which constitute the JET package, the operating system search paths must be set appropriately. This is normally done by the JET installation program. See also the Read Me First file from your on-line documentation.
Keeping in mind future JET ports to other platforms, we introduced a portable notation for file names that may be used in all compiler control files and on the command line. The portable notation combines DOS-like and Unix-like notations (note that on Unix file names are case sensitive):
[ drive_letter ":" ] unix_file_name
c:/jet/bin /mnt/users/Alex/cur_pro MyProject/src/main.class
Along with the base directory macro "$!" (See Control file preprocessing), this portable notation allows you to write control files in a platform independent and location independent manner.
The core part of JET is the jcutility, which combines the compiler with the project subsystem, accompanied with a set of system files /A name of a system file is constructed from the name of the compiler utility and the correspondent filename extension. If you rename the jc utility, you should also rename all system files accordingly./ :
| jc.red | Search path redirection file |
| jc.cfg | Configuration file |
| jc.msg | Texts of error messages |
Upon invocation, jc attempts to locate the jc.red file in the current directory. If there is no such file, it loads the master redirection file from the directory where jc executable resides.
Other system files are then sought by paths defined in the redirection file. If jc.red was not found, or if it does not contain paths for a particular system file, that file is sought in the current directory. If the file is not found, the master file is loaded from the directory where the jc utility resides.
We recommend you not to edit the master redirection file. Instead, use LOOKUP statements in your project files to specify directories for file search and creation. However, if you compile several projects in a single directory, you may wish to create a local jc.red file in that directory.
A configuration file contains default compiler settings for several projects. Project specific settings are defined in project files (See Project files). A so-called template file is used to automate the program build process (See Template files).
A redirection file, a configuration file, and, optionally, a project file (see Project files) constitute the working environment for the given invocation of the jc utility. The compiler preprocesses all those files as described in Control file preprocessing.
JET gives you complete freedom over where to store your bytecode files and files the compiler creates for you. We recommend you to work in a project oriented manner — i.e. to have a separate directory hierarchy for each independent project.
In JET implementation a Java package corresponds to a directory. It imposes the following (quite natural) restriction: since disk location of a package is defined as a directory, location of a subpackage is implicitly defined as a subdirectory of that directory. The default package corresponds to the current directory, but its disk location may be redefined with the help of redirection (See the Redirection file subsection and description of the LOOKUP equation).
A redirection file defines directories and archives in which JET looks for files and creates files. It consists of several redirections of the form /See also Control file preprocessing/ :
Redirection = pattern "=" Location { ";" Location }
Location = ( directory | archive )
pattern is a regular expression with which names of files the compiler has to open or create are compared. A pattern usually contains wildcard symbols "*" and "?", where
| Symbol | Matches |
| * | any (possibly empty) string |
| ? | any single character. |
For a full description of regular expressions see Regular expression.
It is also possible to have comment lines in a redirection file. A comment line should start with the "%" symbol.
directory or archive name may be specified using the portable notation.
You may specify absolute pathnames, such as
/usr/myproj/class
or names relative to the current directory, such as
src/common
denoting the directory src/common which is a subdirectory of the current directory. A single dot in a pathname represents the current directory, a double dot represents the parent, i.e. the directory which has the current directory as a subdirectory.
When looking for a file, jc sequentially matches its name against each pattern. If a match was found, the file is sought in the first of the directories listed on that line, then in the second directory, and so on until either the file is found, or there are no more directories to search or there are no more patterns to match.
If jc could not locate a file which is needed for correct operation, e.g. a necessary symbol file, it terminates with an appropriate error message.
When creating a file, jc also uses redirection: the file is created in the directory that appears first in the search path list following the pattern that matched the file name. If that directory does not exist, it will be created automatically.
If no pattern matching the given filename can be found in the jc.red file, then the file will be read from (or created in) the current working directory.
Note: If a pattern matching the given filename is found then jc will not look into the current directory, unless it is explicitly specified in the search path.
jc can read class files (*.class), symbol files (*.sym), and precompiled files (*.bod) from ZIP and JAR archives. Make sure you specify archive file names with extension:
*.class = ./lib/myLib.jar; /usr/local/jdbc/driver.zip
Note: The compiler cannot write to archive files.
The base directory macro $! can be used in a directory name. It denotes the path to the redirection file. For instance, if the redirection file is placed in the directory /usr/local/jet/bin, then $!/../lib/x86 denotes the directory /usr/local/jet/lib/x86.
Sample redirection file:
jc.msg = /usr/local/jet/bin
*.class = ./myclass
*.sym = sym; $!/../sym.zip
Note: The LOOKUP equation, used in project files and on the command line, extends the list of search paths defined in the redirection file.
JET options allow you to control file placement, code generation, internal limits and settings, etc. We distinguish between boolean options (or just options) and equations. An option can be set ON (TRUE) or OFF (FALSE), whereas an equation has a string value. In this chapter we only describe the syntax of setup directives that define and set options and equations. The full list of jc options and equations is provided in section Compiler options and equations.
Options and equations may be set in a configuration file, on the command line, and in a
The same syntax of a setup directive is used in configuration and project files and on the command line. The only difference is that spaces between tokens are permitted in files, but not on the command line. Option and equation names are case independent.
SetupDirective = SetOption
| ShortSetOption
| SetEquation
| DeclareOption
| DeclareEquation
SetOption = '-' name ('+'| '-')
ShortSetOption = ('+' | '-') name
SetEquation = '-' name '=' [ value ]
DeclareOption = '-' name ':' [ '+' | '-' ]
DeclareEquation = '-' name ':=' [ value ]
All options and equations used by jc are predeclared.
Examples:
| Directive | Means |
| -gendll+ | GENDLL is set ON |
| +gendll | ditto |
| -heaplimit=10M | HEAPLIMIT is set to 10MB |
| -Demo:+ | DEMO is declared and set ON |
| -Vers:=1.0 | VERS is declared and set to "1.0" |
A configuration file is used to set the default values of options and equations (see Compiler options and equations) for all projects (or a set of projects). A non-empty line of a configuration file may contain a single compiler option or equation setup directive (see Options) or a comment. Arbitrary spaces are permitted. The "%" character indicates a comment; it causes the rest of a line to be discarded. Note: the comment character can not be used when setting an equation.
The master configuration file, placed alongside the jc utility, usually contains default settings for the target platform and declarations of platform-specific options and equations, which may be used in project and template files.
Sample configuration file:
% this is a comment line % Set predeclared equation: -heaplimit=32000000 % Set predeclared options: -inline+ % enable inlining -genasserts % do not generate asserts % Declare new options and equations: -rmi:+ -mode:=release % end of configuration file
Note: This section has nothing to do with your application’s memory usage, which is discussed in Memory management.
The JET compiler uses garbage collection to reclaim memory. Most contemporary operating systems, including Linux, provide virtual memory. If the compiler exceeds the amount of available physical memory, the garbage collector becomes very inefficient. Thus, it is important to restrict the amount of memory that can be used by the compiler.
By default, the compiler automatically determines how much memory it may allocate, depending on system load. However, in this mode it will never use more than the amount of available physical memory. So when using JET on low-end systems you may need to specify the maximum compiler heap size explicitly, using the equation COMPILERHEAP. You can modify the default value of that equation in the configuration file (jc.cfg), but for better compiler performance you may need to adjust it on a per-project basis.
Increase COMPILERHEAP if you get the "out of memory" (F950) message. Vice versa, if you notice unusually intensive disk activity when compiling your program, it may indicate that the value of the COMPILERHEAP equation is too large for your system configuration.
The JET compiler is integrated with the project subsystem into a single utility called jc. If invoked without parameters, jc outputs brief help information.
jc command line syntax is as follows:
jc { mode | option | file }
where file, depending on the operation mode, can be a bytecode file name or a project file name. See Compiler operation modes for a full description of operation modes.
option is a compiler setup directive (See Options). All options are applied to all operands, notwithstanding their relative order on the command line. On some platforms, it may be necessary to enclose setup directives in quotation marks:
jc hello.class "-genstacktrace+"
See section Compiler options and equations for the descriptions of all compiler options and equations.
The jc utility receives its options in the following order:
At any point during operation, the most recent setting is in effect. Thus, if the option INLINE was switched ON in the configuration file, but then switched OFF on the command line, the compiler will treat it as OFF.
The JET compiler has the following operation modes:
| Mode | Meaning |
| MAKE | Check dependencies and recompile (default) |
| PROJECT | Build all projects given on the command line |
| HELP | Print help and terminate |
Both the PROJECT and MAKE modes have two auxiliary operation submodes — OPTIONS and EQUATIONS that can be used to inspect the set of compiler options and equations and their values.
On the command line, the mode is specified with the “=” symbol followed by the mode name. Mode names are not case sensitive, and specifying an unique portion of a mode name is sufficient, thus
=PROJECT is equivalent to =p
Operation modes and options can be placed on the command line in arbitrary order, so the following two command lines are equivalent:
jc =make hello.class -inline+
jc -inline+ =m hello.class
jc [=make] { FILENAME | OPTION }
In the MAKE mode, given a set of one or more classes, the compiler automatically determines all classes necessary for their operation. Starting from the classes specified on the command line, jc tries to find bytecode and symbol files of imported Java classes. It then does the same for each of the found classes until all required classes are determined and their bytecode or symbol files are located. If, for a particular class, a bytecode file could not be found, but a symbol file is present, it is assumed that the compiled class resides in a library that will be available at link time. If a symbol file could not be found either, the compiler displays a fault message and terminates. See section Make strategy for more details. All bytecode files found on the previous step are compiled.
Usually, the application’s main class is specified on the command line. In this case, the linker is invoked automatically upon successful compilation. This feature allows you to build simple programs without creating project files.
For convenience, jc also allows you to specify .jar files on the command line:
jc MyApp.jar
jc =project { PROJECTFILE | OPTION }
The PROJECT mode is essentially the same as the MAKE mode except that the classes to be compiled are specified in a project file, which name is passed to jc. A project file specifies compiler options and a set of input files. See Project files for further details.
If file extension is omitted on the command line, jc will append the default extension .prj.
See also:
The OPTIONS submode allows you to inspect the values of options which are set in the configuration file, project file and on the command line. It can be used alone or together with MAKE, and PROJECT modes.
Note: The PRJ option affects the output in the MAKE mode.
In the PROJECT mode options are listed for each project file given on the command line.
See also the EQUATIONS submode.
The EQUATIONS submode allows you to inspect the values of equations which are set in the configuration file, project file and on the command line. It can be used together with MAKE, and PROJECT modes.
Note: The PRJ option affects the output in the MAKE mode.
See also the OPTIONS submode.
In the HELP mode, jc prints information on its usage to the standard output. For instance, run
jc =help optsyntax
to get information on compiler options syntax, or
jc =help genstackalloc
to get help on the option GENSTACKALLOC.
If no topic or option name is specified, the list of available topics is printed.
Upon successful compilation of a class foo, jc produces the following files: a symbol file (foo.sym), an object file (foo.obj), and a precompiled file (foo.bod). The symbol file(foo.sym) contains information required during compilation of classes that import the class foo. To prevent unnecessary recompilation, the compiler first writes symbol information to a temporary file and then compares it with the existing symbol file. If the files are identical, the temporary file is deleted, otherwise the compiler replaces the existing symbol file with the new one.
Examples:
| Command line | Generated files |
| jc Win.class | ~Win.sym |
| ~Win.obj | |
| ~Win.bod | |
| ~Win.rdf | |
| jc com/company/Foo.class | com/company/~Foo.sym |
| com/company/~Foo.obj | |
| com/company/~Foo.bod | |
| com/company/~Foo.rdf |
This section concerns MAKE and PROJECT operation modes. In these modes, the JET compiler builds a set of all class files that constitute the project, starting from the class files specified in a project file (PROJECT) or on the command line (MAKE).
First, the compiler tries to find all given files using the defined lookups.
Then, starting from the explicitly specified files, the compiler tries to find the symbol file and/or the bytecode file for each imported class recursively, until all application classes are located.
If the .class file for a particular class may not be found, and its symbol file is not present either, compilation stops with an error message.
The JET compiler reads the following control files during execution:
All these files are preprocessed when read according to the rules set forth in this section.
A control file is a plain text file containing a sequence of lines. The backslash character ("\") at the very end of a line denotes its continuation.
The following constructs are recognized and handled during control file preprocessing:
Directives have the following syntax (all keywords are case independent):
Directive = "!" "NEW" SetOption | SetEquation | "!" "SET" SetOption | SetEquation | "!" "IF" Expression "THEN" | "!" "ELSIF" Expression "THEN" | "!" "ELSE" | "!" "END". SetOption = name ( "+" | "-" ). SetEquation = name "=" string.
The NEW directive declares a new option or equation:
!new useawt+
!new mode=debug
The SET directive changes the value of an existent option or equation.
!set gendll+
!set main=com/MyCorp/MyPackage/main
The above two directives are typically not used anywhere but in template files, since all other control files permit more convenient syntax described in Options.
The IF directives tell the compiler to process or skip portions of control files depending on the value of Expression. IF directives may be nested.
The syntax of Expression is as follows:
Expression = Simple [ Relation Simple ].
Simple = Term { "+" | OR Term }.
Relation = "=" | "#" | "<" | ">".
Term = Factor { AND Factor }.
Factor = "(" Expression ")"
| String
| NOT Factor
| DEFINED name
| name.
String = "'" { character } "'"
| '"' { character } '"'.
An operand in an expression is either string, equation name, or option name. In the case of equation, the value of equation is used. In the case of option, a string "TRUE" or "FALSE" is used. The "+" operator denotes string concatenation. Relation operators perform case insensitive string comparison. The NOT operator may be applied to a string with value "TRUE" or "FALSE". The DEFINED operator yields "TRUE" if an option or equation name is declared and "FALSE" otherwise.
See project file example in section Project files.
A project file is a plain text file of the following structure:
{ setup-directive }
{ classpathentry-directive | module-directive | batch-directive }
Setup directives define options and equations that all classes which constitute the project should be compiled with. See also Options and Control file preprocessing.
Every line in a project file can contain not more than one directive. A line beginning with the “%” character is considered a comment and ignored.
It is recommended to specify only those settings in the configuration and redirection files which are applied to all your projects, and use project files for all project-specific options and redirection directives.
Project files are subject to preprocessing described in Control file preprocessing.
A simple project file:
-ignoreclassduplication+ -ignorememberabsence+ -classabsence=HANDLE !classpathentry ./SwingSet2.jar -pack=noncompiled -protect=nomatter -optimize=all !end
Typical project file contains some options and equations settings, followed by a list of classpath entries, which describe the directories and JAR files with classes and application resources.
Given the sample project file above, the compiler will compile all classes from SwingSet2.jar, and optimize them for maximum performance. All resource files, such as images, will be packed into the resulting executable and can be loaded at run time.
The above shown project file is a typical example, but it does not cover the advanced lookup and conditional define directives supported by the JET project system.
More complex project file example:
% define default value of the equation 'mode' !if not defined mode then -mode:=work !end % perform conditional settings !if (mode = "work") then % turn off optimizations for faster compilation -inline- % set output file locations -outputdir=debug -lookup=*.sym=debug/stuff -lookup=*.bod=debug/stuff -lookup=*.obj=debug/stuff -lookup=*.rdf=debug/stuff !else % turn on some optimizations -inline+ % set output file locations -outputdir=release -lookup=*.sym=release/stuff -lookup=*.bod=release/stuff -lookup=*.obj=release/stuff -lookup=*.rdf=release/stuff !end % suppress console window at application startup -gui+ % set input file locations -lookup = *.jar = ./lib -lookup = *.class = ./classes;./ext % compile class and all its import !module GUIApplication.class % compile all classes in .jar file !module SampleJAR.jar % compile all .jar files from the 'ext' directory !batch *.jar ext
The more complex project file shown above contains conditional sections that depend on a named variable. If the compiler is run as jc =p advanced.prj, then the value of mode is work; if the compiler is run as jc =p advanced.prj -mode=release, the value of mode is release, and then the other set of directives is used.
A project file can contain several LOOKUP equations, which allow you to define additional search paths. Given the sample project file above, the compiler will search JAR files within ./lib, and class files within ./classes and ./ext directories. Placement for compiler-generated intermediate files (.sym, .bod, .obj, .rdf) is also controlled through the LOOKUP equation, as shown above.
The !classpathentry, !module, and !batch directives are described below.
!classpathentry name
-pack = none | noncompiled | all
-protect = nomatter | all
-optimize= autodetect | all
!end
A classpath entry is a JAR file or a directory that contains either class files, or resource files, or both. Each !classpathentry directive comprises a name, which is a full or relative path to the directory or the JAR file, and up to three equations. The equations specify the optimization, protection and deployment settings for this entry.
Let us consider an example. Suppose your Java application is run with the following command line:
java -cp core.jar;utils.jar;lib\foo.jar com.product.Main
There are three classpath entries:
The respective fragment of the JET project file for such an application would look like this:
% turn on global optimizer +global !classpathentry ./core.jar -pack = noncompiled -protect = all -optimize = all !end' !classpathentry ./utils.jar -pack = noncompiled -protect = nomatter -optimize = autodetect !end' !classpathentry ./lib/foo.jar -pack = noncompiled -protect = nomatter -optimize = autodetect !end
The Global Optimizer uses these settings as follows. The resulting executable will contain all code of core.jar fully protected and optimized for maximum performance. Other classpath entries will be analyzed, and their classes will be divided in two groups:
As you already guessed, the equations protect, optimize and pack directly correspond to the values of Protect, Optimize, and Pack into exe columns of the Classpath grid of the JET Control Panel. Refer to the JET Control Panel chapter for more details.
Note: The protect, optimize and pack equations can be used in the global context, outside of the scope of a !classpathentry directive. In this case, the specified values are used as default settings and can be overridden by the respective equations within !classpathentry directive scope.
!module file-name
file-name is a name of a file which should be compiled, linked, or otherwise processed when a project is being built, e.g. a bytecode file, an additional library, a resource file, etc. The type of a file is determined by its extension (by default .class is assumed). The compiler only processes Java bytecode files (.class, .jar and .zip) and files of a few other types. The remaining files are only taken into account when a response file is created (see Template files).
The compiler recursively traverses imports of all explicitly specified classes (including those in jar files) and builds the full list of classes used in the project. Thus, a project file for an executable program would usually contain a single !module directive for the file which contains the main class and, optionally, several !module directives for dynamically loaded classes that are not explicitly imported, and jar/zip files that have to be compiled entirely.
Note: using !module for adding classes or jar files to the project is obsolete; it is recommended to use the !classpathentry directive instead.
!batch pattern directory
The !batch directive is intended for adding a group of files of the same type to the project’s module list and works as follows:
The !batch directive is typically used for compilation of an entire Java package. Notion of a package corresponds with that of a directory in file system terms. Therefore, to compile the entire package com.MyCorp.MyPkg, you have to add the following line to the project file:
!batch *.class com/MyCorp/MyPkg
Note: the !batch directive is obsolete. It is recommended to put all classes to jars and then use the !classpathentry directive to add the jars to the project.
A rich set of JET compiler options allows you to control the generated code, and the internal limits and settings. We distinguish between boolean options (or just options) and equations. An option can be set ON (TRUE) or OFF (FALSE), while an equation has a string value.
Options control the process of compilation, run-time checks and code generation. An option can be set ON (TRUE) or OFF (FALSE).
A compiler setup directive (See Options) is used to set the option value or to declare a new option.
Options may be set in a configuration file, on the command line, in a project file). At any point of operation, the last value of an
option is in effect.
The alphabetical list of options along with their descriptions may be found in section Options reference.
Table 1. JET compiler options
| Option | Meaning |
| COMPILEWITHFIXEDHEAP | use baseline compiler if there is not enough memory |
| GLOBAL | turns on the global optimizer |
| DISABLECLASSSAVING | disable caching of JIT-compiled class files |
| DISABLESTACKTRACE | disable support for stack trace |
| GENDLL | generate a shared library |
| GENSTACKALLOC | generate code with stack allocated objects |
| GENSTACKTRACE | generate stack trace data |
| GUI | suppress console window Windows |
| IGNORECLASSDUPLICATION | ignore duplicated classes |
| IGNOREMEMBERABSENCE | ignore usage of absent class members |
| INLINE | enable in-line method expansion |
| NOFF | suppress notices |
| VERIFYALL | force strict verification |
| WOFF | suppress warning messages |
This option instructs the JET compiler what to do when it requires more memory than specified by the COMPILERHEAP equation.
If this option is OFF, the compiler terminates with the respective message.
If this option is ON, the method that requires more memory to compile, is compiled in baseline mode — with weaker optimizations. Then, the compilation process continues normally.
When the compiler finishes its job, it prints a notice if some methods were compiled with weaker optimization level, either due to the lack of memory, or due to other reasons. See Baseline compilation for more information.
This option is OFF by default.
This option turns on the global optimizer that compiles classes of your application together with classes of the Java standard API, providing faster startup and smaller download size, at the cost of longer compilation time.
This option is OFF by default.
See Global Optimizer for more information.
The process of JIT cache optimization involves flushing of dynamically loaded class files to the JIT cache directory, enabled by setting the property jet.jit.save.classes. It may be desirable to disable this behavior in the end-user version of the application, e.g. for security reasons. If that is the case, turn this option ON and the JET runtime will ignore the property setting.
This option is OFF by default.
If this option is set ON, stack trace output (see Stack trace) will not work in the resulting executable even if the jet.stack.trace property is set.
Note: The executable will still contain symbolic information used when producing stack trace output, because that information is also required for reflection to work.
You may wish to enable this option when building the end-user version of your application in order to make its reverse engineering more complicated.
This option is OFF by default.
Setting this option ON forces generation of object and symbol files suitable for dynamic linking, and linking them into a shared library.
See Chapter Dynamic linking for details on building shared libraries.
According to the Java Language Specification, all intermediate values in floating point expressions (those of types float and double) that are FP-strict must be elements of the float value set or double value set respectively. This is the default in JET since v3.6.
By setting this option ON, you may allow the compiler to use the extended (80-bit) floating point format for storage of intermediate values. This results in faster code and more precise calculations. However, the results of floating point calculations may not match those yielded on spec compliant VMs, such as Sun HotSpot.
Future versions of Excelsior JET will generate faster code even if the use of the extended format is not allowed.
This option is OFF by default.
If the option is set ON, the compiler places some of the dynamically allocated objects on the stack rather than on the heap. This optimization is performed according with the results of escape analysis and is applied only to short living objects.
According to the Java Language Specification, all objects are allocated on the heap by the new operator. However, a particular object that is never assigned to a static or instance field may be safely allocated on the stack. Typically, these are temporary objects local to a particular method. Stack allocation works much faster and also reduces GC impact on performance.
Note: enabling this option may reduce the program’s scalability as each thread shall require more stack space, so it is recommended to set this option OFF for server-side applications running thousands of threads, if their scalability is more important than throughput.
If this option is set ON, the compiler propagates information about source file names and line numbers into the resulting executable, so that it could appear in the output produced by the printStackTrace() method. Otherwise, such output contains class names only.
Note: The side effect of setting this option ON is the substantial growth (20% or more) of the resulting executable.
The property jet.stack.trace property still has to be set explicitly for stack tracing to work.
This option is OFF by default.
This option is ignored on Linux.
On Windows, if the option is set ON, the compiler generates executables for the Windows subsystem (no console window shall appear when the executable is run by clicking on its name or icon in the Windows Explorer.) Otherwise the compiler generates executables for the console subsystem. This is the default.
Some third-party APIs are known to contain copies of Java platform classes. Platform classes are precompiled into JET runtime shared libraries when you create a profile (see Profiles). By default, the option is ON and the compiler ignores this inconsistency. Warning: The compiler will still use precompiled classes.
By setting this option ON, you force the compiler to issue an error on an attempt to compile a class that was precompiled.
Note: You may override endorsed standards (e.g. packages org.omg.CORBA or org.xml.sax) during profile creation. See Profiles for details.
The option determines the behaviour of the compiler when it is unable to find a class member (field or method) referenced in the code.
By default, the option is ON and the compiler generate code throwing java.lang.NoSuchMethodError or java.lang.NoSuchFieldError for locations where such members are referenced. However, if the code referencing that member never receives control at run time, the program will execute OK on a JVM.
By setting this option ON, you tell the compiler to report errors upon encountering such inconsistencies.
If the option is ON, the compiler tries to expand methods in-line. In-line expansion of a method eliminates the overhead produced by a method call, parameter passing, register saving, etc. In addition, more optimizations become possible because the optimizer may process the actual parameters used in a particular call.
A method is not expanded in-line under the following circumstances:
The equations INLINELIMIT and INLINETOLIMIT control the aggressiveness of this optimization.
See Code performance for more information.
When the option NOFFnnn (e.g. NOFF328) is set ON, the compiler does not report the notice nnn (328 in the above example). See the jc.msg file for notice texts and numbers.
-NOFF+ disables all notices.
When this option is set ON, the compiler verifies that all class files strictly obey language constraints. Otherwise, classes are still verified, but some checks are disabled, namely those that are disabled in Sun HotSpot VM for non-remote classes by default.
This option is OFF by default.
When the option WOFFnnn (e.g. WOFF325) is set ON, the compiler does not report the warning nnn (325 in the above example). See the jc.msg file for warning texts and numbers.
-WOFF+ disables all warnings.
An equation is a pair (name,value), where value is, in the general case, an arbitrary string. Some equations have a limited set of valid values, some may not have the empty string as a value.
A compiler setup directive (See Options) is used to set an equation value or to declare a new equation.
Equations may be set in a configuration file, on the command line and in a project file). At any point of operation, the most recent value of an equation is in effect.
The alphabetical list of equations may be found in section Equations reference.
Table 2. JET compiler equations
| Name | Meaning |
| OPTIMIZE | optimization domain: all classes or auto-detection |
| PROTECT | code protection: complete or partial |
| PACK | deployment mode: all, resource files only, or none |
| CLASSABSENCE | treatment of import of absent classes |
| COMPILERHEAP | heap limit of the compiler |
| DECOR | control of compiler messages |
| DLLNAME | resulting shared library name (deprecated) |
| ERRFMT | error message format |
| ERRLIM | maximum number of errors |
| EXPIRE | expiration date for creation of trials |
| EXPIREMSG | expiration message |
| HEAPLIMIT | generated program heap limit |
| IMAGEBASE | executable image base Windows |
| INLINELIMIT | maximum size of inlineable method |
| INLINETOLIMIT | maximum size of inlined-to method |
| JETVMPROP | hardwired system properties |
| JETRT | JET runtime flavor |
| LINK | linker command line |
| LOOKUP | file lookup paths |
| MAIN | application main class |
| OUTPUTDIR | target directory |
| OUTPUTNAME | resulting executable name |
| PRJ | project file name |
| PROJECT | project name |
| SPLASH | splash screen image |
| SPLASHCLOSEONTITLE | splash auto hide mode |
| SPLASHMINTIME | splash delay |
| STACKLIMIT | generated program stack limit |
| TEMPLATE | linker response file template |
Sets optimization mode. Valid values are “ALL”, and “AUTODETECT”.
If set to “ALL”, all class files are compiled to native code with current optimization settings. Typically, this mode provides the best performance, however, the size of resulting executable may be quite large.
If set to “AUTODETECT”, the compiler detects which classes will be used at run time, and optimizes those classes only, leaving the rarely used code in compact, but no-optimized form. This mode provides smallest binaries, but it may negatively affect application performance, if the compiler assumptions fail.
If this equation is placed within a “!classpathentry .. !end” scope, it affects that classpath entry only. Otherwise, the setting has global effect.
Sets code protection mode. Valid values are “ALL”, and “NOMATTER”.
If set to “ALL”, all class files are compiled to native code, thus protecting them from reverse engineering.
If set to “NOMATTER”, the JET Optimizer may avoid compilation of some classes in favor of reducing the download size of the application.
If this equation is placed within a “!classpathentry .. !end” scope, it affects that classpath entry only. Otherwise, the setting has global effect.
If set to “NONCOMPILED”, everything but compiled .class files is packed to the executable. This is the default mode. Simply speaking, in this mode non-compiled class files and all resource files are packed to the executable, and can be accessed by the application at run time. The original classpath entry is no longer required for the running application.
If set to “NONE”, neither original class files, nor resource files are packed into the executable. The classpath entry should be distributed along with the application executable.
If set to “ALL”, all class and resource files are packed to the executable. This makes sense when compiling JARs of security providers and other APIs that require class files to be available at run time.
If this equation is placed within a “!classpathentry .. !end” scope, it affects that classpath entry only. Otherwise, the setting has global effect.
This equation controls the actions taken by the compiler when it is unable to find an imported class.
Valid values are “ERR”, and “HANDLE” (the default).
If set to “ERR”, the compiler reports an error if an imported class is unavailable. You should add the location containing that class file to the classpath. You may use the mode to force the compiler to perform consistency checks for the set of compiled classes.
However, if that imported class is not actually used at run time, the program will execute OK on a JVM. This bytecode inconsistency is often present in third-party libraries. If you encounter such problem, switch this equation back to “HANDLE”. If some of the absent classes become available, they will be loaded by the JET’s dynamic compiler (reflective shield) and the program will execute correctly, though loss of performance is possible.
Sets the maximum amount of heap memory (in bytes), that can be used by the compiler. For systems with virtual memory, we recommend to use a value which is less than the amount of physical memory.
See Compiler memory usage for more information.
The equation controls output of the jc utility. The value of equation is a string that contains any combination of letters "h", "p", "r", "t" (capital letters are also allowed). Each character turns on output of
By default, the equation value is "hrt".
This equation has to be set to the name of the DLL into which the currently compiled class will be linked. It has no effect if GENDLL option is OFF.
This equation has been superceded by OUTPUTNAME. It is still recognized by the compiler, but may be removed in future versions. The JET Control Panel does the replacement automatically when you open a “legacy” project.
Sets the error message format. See Error message format specification for details.
Sets the maximum number of errors allowed for one compilation unit (by default 16).
Set an expiration date for the resulting executable. The value is the expiration period that is either a number of days after the build date of the executable or a fixed date (both formats are supported.)
See Creating trial versions for details.
Set an expiration message for the resulting executable. The value is the message text to be displayed as the evaluation period is over.
See Creating trial versions for details.
Hides the splash screen when the application opens a window whose title starts with the specified prefix. The value is the prefix string.
See Suppressing a splash for details.
Sets the maximum amount of heap memory that can be allocated by the generated program. The value may be set in bytes, kilobytes (’K’ suffix), or megabytes (’M’ suffix). We recommend to set it in a project file or the configuration file.
The value of 0 (zero) has a special meaning — adaptive heap size. It this case, the maximum amount of memory the application may allocate before garbage collection occurs is determined at runtime using certain heuristics that take overall system load into consideration.
The size of such adaptive heap never exceeds 75% of the total amount of physical memory available to the system.
Note: Adaptive heap has a slight negative effect on performance, so it is highly recommended to specify heap size explicitly when possible.
This equation is ignored on Linux.
By default, all Windows executables (EXEs and DLLs) produced by the JET compiler use the same image base address, which is 0x400000. You change the default base address by setting this equation:
-imagebase=0x10000000
Sets the maximum size of method that may be considered for inline substitution into another method (see the option INLINE). The units are syntax tree nodes. The compiler multiplies this limit by certain factors greater than one if the method is called inside a (nested) loop.
See also INLINETOLIMIT.
Sets the maximum size of methods permitting inline substitution (see the option INLINE). The units are syntax tree nodes. Methods of size up to INLINETOLIMIT*2 permit inlining in some special cases, such as inlining of small methods that do not call other methods except from throw/catch.
See also INLINELIMIT.
Defines system properties to be hard-wired into the output executable.
-JETVMPROP=-Dp1name -Dp2name:p2value
See Java system properties for more information.
This equation controls the JET runtime flavor that serves the compiled application.
Valid values: “CLASSIC”, “DESKTOP”, “WORKSTATION”, and “SERVER”.
See Runtime Selection for more details.
Note: Desktop, Workstation, and Server RT are available only in the Professional Edition.
Defines the command line to be executed after successful compilation of a project. As a rule, the equation is used for calling a linker or make utility.
Normally, you do not need to change the default value of this equation.
The equation is used to define additional search paths that would complement those set in the redirection file.
Syntax:
Lookup ::= -LOOKUP = RegExp = Source {";" Source}
Source ::= Directory | Archive
jc can read class files (*.class), symbol files (*.sym), and precompiled files (*.bod and *.rdf) from zip and jar archives. Make sure to specify archive file names with extensions. A configuration or project file may contain several LOOKUP equations; they are also permitted on the command line.
Example:
-lookup=*.class=./class;/usr/local/MyJars/MyLib.jar
See also Redirection file and Project files.
By default, upon encountering a method with signature static public void main (String[]), the compiler designates it as a program’s starting point. If your program contains more than one class with such method, the linker would report duplicate names and fail to build the program. This equation allows you to explicitly specify the name of the class, the main method of which has to be the program’s entry point.
Notes:
-main=com/MyCompany/MyMainClass
This equation can be used to specify the pathname of the directory into which the compiler places the resulting file (executable or shared library.) If this equation is not set, the target directory is defined as follows:
This equation can be used to explicitly set the name of the resulting file (executable or shared library). If this equation is not set, the name is computed as follows:
Note: If the result will be a shared library, its name must be known at compile time. Do not rename shared libraries created by JET if they will be referenced from other JET-compiled executables.
See Building multi-component applications for more information.
In the MAKE operation mode, this equation defines a project file to read settings from. In the PROJECT mode, the compiler sets this equation’s value to the project file name from the command line. See PROJECT mode.
If a project file name is defined, the compiler sets the equation to a project name without file path and extension. For example, if the project file name is prj/Work.prj, the value of the equation is set to Work. The equation is typically used in template files, for instance, to set the name of the executable file.
Sets the maximum size of the stack in the generated program. The value is set in bytes.
Assigns the resulting executable a splash screen image. The value is the full path of a .bmp file. The current implementation supports only bitmap images (the BMP format with 24-bit color depth.)
See Displaying a splash for details.
Hides the splash screen when the application opens a window whose title starts with the specified prefix. The value is the prefix string.
See Suppressing a splash for details.
Delays the splash on the screen for the specified time (unless the user clicks on it.) The value is the delay in seconds.
See Suppressing a splash for details.
Specifies the linker response file template. See Template files.
In project files created by the JET Control Panel, you may encounter certain internal options and equations not described in the previous sections. You should not use these options and equations when writing project files manually or editing auto-generated projects.
This chapter gives explanation for compiler diagnostics. For each error, an error number is provided along with a text of error message and an explanation. An error message can contain a format specifier in the form %d for a number or %s for a string. In this case, an argument (or arguments) is described on the next line.
In most cases the compiler prints a source line in which the error was found. The position of the error in the line is marked with a # sign placed directly before the point at which the error occurred.
A referenced field or method does not exist in the imported class. This is typical situation in big projects.
Suggested solution: switch to the Options Page, select the Advanced tab, and set the Ignore member absence mode. Please refer to JET consistency checks for more details.
This warning is issued if the option IGNOREMEMBERABSENCE is ON and a field not present in an imported class is referenced in the program.
This warning is issued if the option IGNOREMEMBERABSENCE is ON and a method not present in an imported class is referenced in the program.
The compiler could not determine the program’s entry point because no class in the compilation set has a method static public void main (String[]). Add a class with such method to the compilation set.
The class specified in the MAIN equation could not be found along the classpath. Add the appropriate directory, jar, or zip file to the classpath or adjust the value of the MAIN equation.
The class you specified in the MAIN equation was found, but it turned out that the method public static void main(String[]) is absent. Check that the correct version of the class is accessible to the compiler, or specify a different class. Valid values for the MAIN equation are listed below the error message.
There is more than one class having a method public static void main(String[]) in the classpath, so the compiler cannot designate the program’s entry point automatically. Specify the name of the desired class using the MAIN equation, valid values for which are listed below the error message.
The file is specified as a part of the project file but could not be found, perhaps you deleted it by accident. If you created the file manually, recreate it again. If the file ends with ".usg", it was automatically generated. In this case, use the test run to re-generate it.
One of the .usg files included to your project contains syntax errors as a result of manual editing. If you intend to edit.usg files, contact Excelsior for details on their syntax.
Neither symbol nor bytecode file could not be found for an imported class.
There is a chance you missed a JAR file when specifying the class path for your project. If this is the case, add the JAR file on the Start Page.
If you are sure all relevant JARs and directories with class files are specified, switch to the Options Page, select the Advanced tab, and set the "Class absence results in" combo box to "Dynamic compilation". Please refer to JET consistency checks for more details.
Classpath entries of your project contain two or more copies of the same class file. Please switch to the Options Page, select the Advanced tab, and set the "Ignore conflicting classes" mode. Please refer to JET consistency checks for more details.
The specified file could not be created.
Most probably, you do not have sufficient access rights. Also check if the file system is full.
The specified file could not be opened.
You do not have sufficient access rights or the file is already opened in exclusive mode.
Compiler encountered a difference between name of a class and name of a file this class is defined in. Usually, this happens when a file name and a class name differs with case only (like file Hello.class with class hello in it).
Solution: Provide JET with correct case-sensitive class name (either in project file or in command line).
See description of the !classpathentry directive for details on the syntax and possible values of these equations.
Since version 4.5, JET uses new syntax for describing classpath entries where class files and resources can be found. Therefore, when reading project file with obsolete options, the warning is issued.
These options are fully supported, so you may ignore the warnings safely. However, we recommend you to read the description of the !classpathentry directive for details on the PACK equation syntax and its possible values.
The usage list file (.usg) contains references to the entities not found in your project. Typically, this happens when the application is updated, while the .usg file is not. Recreate your .usg file using the test run.
JET failed to rename the file before overwriting it with the fresh copy. Make sure the current user has write/rename rights to the given file.
The usage list file (.usg) is obsolete. Recreate it using the test run.
Your project file contains a syntax error. Please refer to the description of the !classpathentry directive for details on its proper syntax.