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 amout 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 intergrated 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 succesful 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 | |
| jc com/company/Foo.class | com/company/~Foo.sym |
| com/company/~Foo.obj | |
| com/company/~Foo.bod |
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 }
{ 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.
Example of a project file:
-lookup = *.class = $!/class -lookup = *.sym = ./sym; $(JET_HOME)/sym % check project mode !if not defined mode then % by default use debug mode !new mode = debug !end % set options according to the mode !if mode = debug then -lookup = *.class = ../MyLib/Debug !else -lookup = *.class = ../MyLib/Final !end !module hello !module hello.res
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 for files with .class extension using search paths specified in the project file before the paths specified in the redirection file.
A project file is specified explicitly in the PROJECT operation mode. In this mode all options and equations are set and then the compiler proceeds through the list of input files to gather all classes constituting the application (See Make strategy).
In the MAKE operation mode, a project file can be specified using the PRJ equation. In this case, the module list is ignored, but all options and equations from the project file are set.
The following command line forces the compiler to compile the class hello.class using options and equations specified in the project file hello.prj:
jc hello.class -prj=hello.prj
!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. At least one !module directive must be present in a project file.
!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
In project files created by the JET Control Panel, you may encounter certain internal directives not described in the previous sections. They are shortly described below for your reference.
Note: you should not use these directives when writing project files manually or editing auto-generated projects.
!push
!pop
The !push/!pop directives open/close a new scope for options and equations in the project file. If you are going to modify a project created by the JET Control Panel, you have not to insert any options or equations between !push and !pop. If you wish to specify an additional setting, you may always do that in the beginning of the project file.
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 |
| PACKCLASSES | pack class files and resources into the executable |
| PACKRESOURCES | pack resources only into the executable |
| 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 affects processing of jar files specified using !module directives or on the jc command line.
If the option is set ON, and the option PACKRESOURCES is also set ON, class files are not removed from jars packed into the resulting executable. As a result, the original class files shall be available at run time, which is required for supporting JCE (Java Crypto Extension) and related APIs.
This option is OFF by default.
See Resource packing for more information.
This option affects processing of jar files specified using !module directives or on the jc command line.
If the option is enabled, those jar files are packed into the resulting executable. That enables creation of self-contained executables that do not require distribution of separate jars with resource files (icons, images, sounds, etc.).
By default, class files are filtered out from jars duiring the packing process. However, some APIs, such as JCE, require class files to be present at run-time. Set the option PACKCLASSES ON to pack the entire jars with class files.
This option is OFF by default.
See Resource packing 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.
This option is now obsolete and recognized for backward compatibility only. You should use the equation CLASSABSENCE instead. The JET Control Panel does the replacement automatically when you open a “legacy” project.
Some third-party libraries are known to contain copies of Java 2 platform classes. Platform classes are precompiled into JET runtime shared libraries when you create a profile (see Profiles). By default, the compiler reports an error on an attempt to compile a class that was precompiled.
By setting this option ON, you force the compiler to issue warnings instead of errors upon encountering duplicated classes. Warning: The compiler will still use precompiled classes.
You may override endorsed standards (e.g. packages org.omg.CORBA or org.xml.sax) during profile creation. See Profiles for details.
By default, the compiler reports an error if it is unable to find a class member (field or method) referenced in the code. 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 issue warnings instead of errors upon encountering references to absent class members. The compiler will report a warning and will generate code throwing java.lang.NoSuchMethodError or java.lang.NoSuchFieldError for locations where such members are referenced.
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 optiomization.
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 |
| CLASSABSENCE | treatment of import of absent classes |
| COMPILERHEAP | heap limit of the compiler |
| COMPONENTCLASSPATH | CLASSPATH setting |
| 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 |
This equation controls the actions taken by the compiler when it is unable to find an imported class.
Valid values are “ERR”, and “HANDLE”.
If set to “ERR” (the default), 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 inconsitency is often present in third-party libraries. If you encounter such problem, switch this equation 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 performace 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.
New in v4.1:
This equation specifies the classpath, an ordered list of jar/zip files and directories where the JET Runtime will look for classes and resources necessary to the component (executable or shared library) created with this project file.
Note: You should not use the equation if all the resources are to be packed into the component during compilation (see Resource packing.)
If the order of the classpath entries is not important, you can safely omit the packed resources and specify only the list of separate resources /The JET Runtime will automatically add the packed entries to CLASSPATH./ . It should include pathnames separated by ":" , for example
-COMPONENTCLASSPATH=./images: /usr/local/MyRes/S.jar
If, however, the application relies on a particular order of the classpath entries, you should specify the entire classpath including packed jar/zip files. Note that unlike pathnames of separate resources, the packed jar/zip files should be referenced using their short names, for example
-COMPONENTCLASSPATH=MyLib.jar: /usr/local/MyRes
In addition to lookup of classes and resources by the JET Runtime, this setting will be used by JetPackII wizard when preparing an installation including this executable component (see Step 3: Setting Up Separate Resources and Java System Properties.)
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 recoginzed 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) 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
New in v4.1:
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. They are described below for your reference.
Note: you should not use these options and equations when writing project files manually or editing auto-generated projects.
Specifies the JetPackII project last used for creating an installation including this executable or shared library. It is solely used by the JET Control Panel to invoke the JetPackII wizard against an appropriate project file.
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 error typically occurs when class files go out of sync. You may need to recompile your Java sources. If this error is reported for a third-party class file, to which sources you do not have access, you may consider using the option IGNOREMEMBERABSENCE. Refer to its description for more information.
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.
Neither symbol nor bytecode file could not be found for an imported class.
Make the symbol or bytecode file available to the compiler. If this error is reported when compiling a third-party class file, and you do not have and cannot obtain the imported class, consider using the equation CLASSABSENCE. Refer to Bytecode consistency checks for more information.
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).
A symbol file for the given class is corrupted. Recompile it.
The given symbol file was generated by a different version of the compiler. Recompile the class file or use the respective versions of the compiler and/or symbol file.
The error occurs if a symbol file was changed but not all its clients (classes that uses it) were recompiled. For example, if class A uses classes B and M and B in turn uses M:
class M {
}
class B extends M {
}
class A {
B b;
}
Let us recompile M.class, B.class, and then add a new instance field in M and recompile it again. The error will be reported when compiling A.class, because version keys of module M used through B is not equal to the version key of M used directly.
To fix the problem modules must be compiled in appropriate order. We recommend to use the JET compiler make facility, i.e. to compile your program in the MAKE or PROJECT operation mode. If you always use the make facility this error will never be reported.
A symbol file name (without the .sym extension) must be equal to the actual name of the class.
In many cases a warning may help you to find a bug or a serious drawback in your source text. We recommend not to switch warnings off and carefully check all of them. In many cases warnings may help you to find and fix bugs very quickly.
This variable is of no use, it is not exported, assigned, passed as a parameter, or used in an expression. The compiler will not allocate space for it.
This parameter is not used in the method.
This method is not exported or called. The compiler will not generate it.
Execution of this loop (while, for or do) will not terminate normally. It means that statements after the loop will never be executed and the compiler will not generate them. Check that the loop was intentionally made infinite.
This code cannot be executed and the compiler will not generate it (this is called dead code elimination). It may be statements after a return or throw, infinite loop, statements under constant false condition (if (false)), etc.
It may be a loop like
for (i=1; i<2; i++) ...;
or
while (true) { ...; break;}
Check that you wrote it intentionally.
The compiler was able to determine the run-time value of the given variable (due to constant propagation) and will use it instead of accessing the variable. For the following example:
i=5; if (i == 5) S;
the compiler will generate the code as if the source was:
i=5; S;
This warning is reported for local variables only.
After constant propagation, the compiler determined that the value of an object variable is null when access to its instance field or method occurs, e.g:
p=null;
p.field=1;
The code will be generated and will throw "NullPointerException" at run-time.
This warning is reported for local variables only.
The for statement is redundant (and not generated) if its body is empty or it may be determined at compile-time that it would be executed zero times.
This warning is reported if a program fragment does not influence flows of control and data, e.g:
i=1;
i=2;
The first assignment is redundant and will be deleted (unless i is decalred as volatile).
The same as W900, but the redundant code is preserved because it can throw an exception, e.g.:
i = a / b; (* would throw exception if b == 0 *)
i=2;
The warning is reported if a boolean condition can be evaluated at compile-time, for example:
if (i==1 & i==1) (* the second condition is true *)
or
j=2;
if (i==1 | j!=2) (* the second condition is false *)
The compiler ignores method result, like in:
if (foo());
This section describes errors reported by a native code generator (back-end). The code generator is invoked only if no errors were found by a language parser.
The compiler cannot generate your class. Try to increase COMPILERHEAP. Note, that the memory required for the code generator depends mostly on a method size.
The compiler has failed to generate an expression due to its complexity. This should not normally occur. If you see this message, please file a defect report.
Internal compiler errors usually indicate a compiler bug, but may also occur as a result of inadequate recovery from previous errors. In any case we recommend to provide us with a bug report, including:
Example:
INTERNAL ERROR(ME): value expected
An unrecoverable error occured, causing immediate termination of the compiler. This message in most cases indicates a compiler bug. For instance,
compilation aborted: invalid location
means that the compiler has attempted to access memory at an address that is not valid.