Note: information in this section is not applicable to the Standard Edition of Excelsior JET.
Excelsior JET VM comes with multiple implementations of the runtime system, optimized for different hardware configurations and application types. It enables your application to effectively utilize the computing power of systems that support parallel execution /Examples are multi-processor servers, multi-core chips and CPUs that support Hyper-Threading Technology/ , thereby improving performance.
This section describes the available runtime systems and helps you select the proper runtime for your applications and target system configurations.
The Desktop Runtime is suitable for applications that typically run on conventional desktop and notebook computers. It is optimized for single- and dual-CPU systems, including those based on Hyper-Threading-enabled processors and dual-core desktop chips. This is the best choice for rich clients, visualization and engineering design tools, and other desktop applications.
The Server Runtime fits best for highly concurrent server applications. It provides out-of-the-box performance and scalability and takes full advantage of the computing power of multi-processor hardware. Note that Excelsior JET, Enterprise Edition is the only retail version that includes the Server Runtime.
The Classic Runtime is designed to use on low-end hardware which does not support parallel execution such as uniprocessor systems equipped with old CPU models of the x86 architecture. It is not recommended for use on HyperThread/multi-core CPU and multi-processor systems.
The Classic runtime was the only option in Excelsior JET prior to version 3.7, hence its name. Currently, it is the only option in the Standard Edition of Excelsior JET.
Basically, you select an Excelsior JET Runtime depending on the type of your application and hardware configurations of the systems to which it will be deployed. To make the right choice, follow the recommendations below.
If your server application will be deployed to high-end multi-processor machines, opt for the Server Runtime. Other Runtimes are not optimized for N-way systems so choosing them would significantly degrade the throughput of the server. For low-end uniprocessor and 2-way servers, the Desktop Runtime fits best.
In most cases, the Desktop Runtime is the optimal choice for desktop applications running on single- and dual-CPU systems.
Note that using the Classic Runtime on the systems that support parallel execution, such as Intel P4 powered by the Hyper-Threading technology, may cause significant performance degradation.
If your embedded platform is equipped with a CPU that does not support parallel execution /For instance, a Pentium II-class processor/ , the Classic Runtime fits best. Otherwise, use the Desktop Runtime.
You may experiment with each runtime flavor as described in the next section.
You select the runtime when compiling your application. The JET Control Panel shows the available RT options on the Target page. If you use the command-line interface to the JET compiler, specify the JETRT equation in the project file:
-JETRT=DESKTOP
Finally, if you run your application via the xjava launcher, use the -Xrt option to select the desired runtime (see Options):
xjava -Xrt=server -jar MyServer.jar
You may also select the runtime at application launch time specifying the jet.rt property (see How to set system properties). For example, to enable the Classic Runtime, specify
-Djet.rt:classic
The valid values are classic, desktop, and server.
Note, however, that the jet.rt property can only force lower-end runtimes /In the sense of this order: Classic < Desktop < Server/ than the runtime selected at compile-time. For instance, if you chose the Desktop Runtime when compiling your application, you may force the Classic Runtime during its launch, but not the Server Runtime. If you wish to test your application against all runtimes, enable the Server Runtime when compiling and then select other runtimes using the jet.rt property as desired.
If you used any optimizing compilers before, you must have experienced a situation when a particular combination of the many available optimization control options results in incorrect code being generated by the compiler for your program, or when the program only works properly when compiled with debug information generation enabled. The reason is that a compiler with dozens of optimization control options is extremely difficult and expensive to test, as the compiler manufacturer has to check all possible combinations of options, so no vendor does that.
Fortunately, this is not the case with JET. Unlike many other compilers, JET always optimizes code to the maximum extent possible. Even enabling generation of debug information to ease field engineering does not affect the output code. The only two optimizations that may be disabled or adjusted are stack allocation of objects and inline expansion of methods, because they can negatively affect scalability (see Number of threads) and code size of the resulting program.
To get the maximum performance, do the following:
+GENSTACKALLOC
+INLINE -INLINELIMIT = 200 % default is 100 -INLINETOLIMIT = 2000 % default is 1000
Inline expansion should be used with care. It allows the compiler to substitute a method in-line, if that method is declared as final or if compile time analysis confirmed safety of such substitution. As a rule, enabling inline expansion results in faster but bigger code. However, the effect of this optimization depends on the programming style (sizes of methods, etc). You may control inlining aggressiveness using equations INLINELIMIT and INLINETOLIMIT in the project file, or by selecting one of the presets in the Inline expansion list in the Control Panel.
JET is fully SMP-aware, so your compiled applications will scale to multiple processors automatically. However, you should select the Desktop or Server Runtime to enable the most effective utilization of several CPUs (see Runtime Selection). You may wish to fine tune the garbage collector as described in Parallel hardware.
Excelsior JET runtime maps Java threads directly onto native operating system threads. Windows reserves the same amount of address space for the stack of each thread of a particular process, which is retrieved from the size of stack reserve field of its EXE header.
The default size of stack reserve is about one megabyte, which basically means that if your program attempts to run 1,000 threads simultaneously (which is not unusual for server-side applications), their stacks will claim one gigabyte of the process’ virtual address space, of the total of four gigabytes. Given that some part of the virtual address space is reserved by the operating system (Windows reserves half of it, i.e. 2GB), one process cannot run more than a few thousand threads simultaneously with that default setting.
An attempt to run too many threads simultaneously in a Java application results in OutOfMemoryError. Waste of address space for thread stack reserves also effectively limits the amount of memory that the memory manager may allocate from the OS and thus may also cause OutOfMemoryError.
To reduce the default stack size and thus improve the scalability of your application with respect to the number of threads:
-STACKLIMIT=65536
This is equivalent to setting the -Xss option of the standard Java launcher.
Another thing to consider is that enabling stack allocation of objects increases the compiled programs’s stack size requirements, negatively affecting its scalability. Therefore, you may wish to disable this optimization by unchecking the Allocate objects on the stack box on the Options page (see Optimizations) or turning the GENSTACKALLOC option off in the project file. This would enable you to further reduce the thread stack size as described above, thus letting your application run more threads simultaneously at the cost of minor performance loss.
A Java launcher allows you to set a system property using the -D command-line switch, for instance:
java -Dp1name -Dp2name=p2value MyApp arg1 arg2
A JET-compiled application is a conventional executable file that is run by itself:
MyApp arg1 arg2
so there is no place to set a property on the application’s command line.
JET provides three ways to set system properties for your compiled application:
-JETVMPROP=-Dp1name -Dp2name:p2value
SET JETVMPROP=-Dp1name -Dp2name:p2value
MyApp arg1 arg2
Warning: The JETVMPROP environment variable is intended to be used during development and field engineering. Normally, you should hardwire the necessary system properties into the executable at compile time or install time as described above. If you need to override the hardwired properties at launch time, use a batch file for launching your application. Never set the JETVMPROP environment variable globally (i.e. in the Windows registry or AUTOEXEC.BAT) on enduser systems as it may cause other JET-compiled applications to misbehave.
If the xjava utility is used to run your application, you can either use the JETVMPROP environment variable or follow the standard java command line syntax for setting the properties:
xjava -Dp1name -Dp2name=p2value MyApp arg1 arg2
Notes:
The JET runtime recognizes the following properties:
Sets the maximum heap size to the given amount of bytes (kilobytes or megabytes respectively if either of the suffixes k or m is present), overriding the compile-time heap size setting. Setting size to zero enables adaptive heap size. See Memory management for more information.
Specifies the maximum proportion of CPU time to be allocated to the garbage collector at runtime, in 1/1000ths. See GC ratio for details.
Select a specific JET Runtime. Valid values of flavor-name are classic, desktop, workstation, and server.
See Runtime Selection for details.
Sets the maximum number of concurrent threads that may be used for garbage collection. By default, N equals the number of processors on the system. See Parallel hardware for more information.
Enables caching of JIT compilation results. See Using the mixed model for more information.
Designates path as the JIT compiler cache directory. See Using the mixed model for more information. This property is effective only if caching of JIT compilation results is already enabled.
Sets maximum amount of memory the JIT compiler is allowed to use. Default value is 128 megabytes. Use this option to increase amount of JIT memory if an OutOfMemoryError is thrown as a result of JIT compilation.
Logs names of DLLs loaded by the application at run time into a file.
Enables stack backtracing facility. See Stack trace for more information.
Forces the optimizing JIT compiler. See JIT compiler selection for more information.
Forces the fast JIT compiler. See JIT compiler selection for more information.
Forces the JET Runtime to postpone compilation of dynamically loaded classes to the latest possible moment (i.e. a lazy resolution technique is used.) Specifying this option reduces JIT pauses at the cost of possible performance degradation for JIT-compiled classes.
Allows customizing the error messages printed after a JET Runtime crash. For more details, refer to section Customizing Runtime error messages.
Excelsior JET lets you define the policy of memory management to be used for your Java application at run time. This section describes a few simple mechanisms that you can employ to set an optimal balance between performance of the application and its memory footprint.
Ideally, an application should work fast enough and consume as few memory as possible. In practice, there are always trade-offs between application performance (or throughput) and its memory footprint. What’s especially important is that performance and memory requirements are application-specific. For one program, performance is critical, whereas low memory footprint has more value for the other. Put simply, one size does not fit all.
Fortunately, the JET Runtime lets you fine tune the performance/memory balance for your Java application. For that, you just set a ratio in which the Runtime will portion out execution time between the two tasks: execution of the application’s code and garbage collection. This technique is simple and effective:
You can do that by specifying the GC ratio setting to the JET Runtime. Its value is the tenths of percent of total CPU time that may be spent for garbage collection. For example, the default GC ratio is 1.1% which means that GC will normally take the percentage in total execution time. You can vary the GC ratio as follows.
-Djet.gc.ratio:50
Note: changing the default GC ratio is not available in the Standard Edition of Excelsior JET.
The default setting (1.1%) is biased to performance and, therefore, may cause excessive memory consumption in some cases. You can experiment with your Java application by fine tuning the GC ratio. Often, increasing the value by several units may noticeably reduce memory footprint. That’s why the unit of measure is 1/10th of percent not a whole percent.
One might question: what reduction in memory footprint can I expect when increasing the GC ratio by X%? In general, it depends on two factors: how much garbage your application produces and how fast it does that. Thus, the answer is specific to a particular application.
Note that under certain circumstances, the JET Runtime is unable to meet the GC ratio requirement. For example, if a Java application allocates objects very intensively and amount of available physical memory is low, more CPU time may be spent in the garbage collector regardless of the ratio specified.
Finally, you may set the GC ratio to 0 to entirely disable the mechanism (it’s not recommended, though.) In such case, GC is automatically invoked only if the JET Runtime is unable to serve a regular request for object allocation due to memory constraints as described in the following sections.
You may specify the maximum amount of heap memory that your application is allowed to allocate at run time /The respective command line parameter of the standard Java launcher is -Xmx/ :
-HEAPLIMIT=30m % maximum heap size is 30MB
To override the compile-time setting, you may set the system property jet.gc.heaplimit, e.g.
-Djet.gc.heaplimit:35m
You need to specify the maximum heap size only if you do not want the Java heap to exceed certain upper bound in any case. On the one hand, it may be useful to reduce application memory footprint. On the other hand, it may compromise performance of your application. For example, it might work more effectively when using large Java heaps on the target machines that have high RAM capacity.
The default value of the maximum heap size is 0 which means Adaptive. In this mode, the Java heap is only bounded by the size of Virtual Address Space that varies from 2 to 4GB, depending on the underlying operating system. But do not be afraid. It does not mean that your application will take gigabytes of memory at run time. First, the JET Runtime checks the GC ratio which effectively damps inflation of the heap. Moreover, the runtime constantly monitors the amount of available physical memory as described in the next section.
As a rule, it’s hard to determine the "right" application memory settings because they are specific to a particular target system. For instance, you consider a box equipped with 256MB of RAM as a "typical target system" but some customers are proved to be still using 128MB machines. Another example is a system under heavy workload: imagine that your application runs simultaneously with a couple of other programs hungry for memory. Anyway, your application must work, more or less efficiently.
To address these problems, the JET Runtime considers the amount of available physical memory in the system to schedule garbage collection. If low memory is detected when allocating an object, GC is activated to avoid unnecessary swapping RAM pages to the hard disk. Of course, it leads to more frequent GC invocations and penalizes application performance. But it’s a good alternative to tremendous overheads of swapping memory to and from.
However, if the runtime detects that application execution has degraded to sole garbage collection or it’s unable to allocate an object even after GC invocation, the physical memory boundary is crossed. The JET Runtime augments the Java heap with the amount of memory enough to serve the allocation request plus some decent gap necessary for further operation. Often, this move helps to clear the air. The operating system reacts to the event and fetches memory, e.g. from the system cache, so that the application continues running smoothly.
You have control over the JET Runtime with respect to crossing the physical memory threshold. To override the default behavior
The theoretical limit of the heap size for 32-bit applications is 4 gigabytes. In practice, however, a part of the virtual address space is occupied by the operating system, thread stacks, program executable and dynamic libraries, etc. As a result, the application cannot allocate a multi-gigabyte heap even if the system has enough physical memory.
The upper bound of the maximum possible heap size is O/S-dependent. If you run a JET-compiled application on 64-bit Windows or Linux, it is able to allocate up to 3GB of heap memory without hassles. However, care must be taken if the system requirements of your Java application include 32-bit Windows and/or Linux flavours. Typically, all the systems allow allocation of a 1.5 GB heap out-of-the-box provided the machine has enough RAM. This can be considered as the “largest common denominator”.
Certain 32-bit operating systems, e.g. Windows 2003 Server, can be configured to enable allocation up to 3 GB heap as well. For more details, refer to
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
In addition, some Linux distros provide an option to build the kernel in a special mode that makes approx. 4GB address space available to the process. For example, RedHat Enterprise Linux 3 and higher include a kernel known as the hugemem kernel. Note that this incurs some overhead when transferring from user to kernel space, e.g. in the case of system calls and interrupts.
If your target systems have multiple CPUs, or support parallel execution via multicore or hyperthreading technology, select an appropriate version of the JET Runtime as described in section Runtime Selection. The right choice of Runtime has a great impact on performance of applications that use the Java heap intensively.
Moreover, on the parallel hardware, the garbage collector runs in multiple threads to reduce collection pauses. By default, the total number of concurrently working GC threads equals the number of CPUs reported by the operating system. However, you may reduce this number for optimum system performance, e.g. if you want one or more CPUs to be available to some native threads or processes running at the same time.
For that, set the value of the jet.gc.threads property to the maximum number of GC threads. For instance, to make the garbage collector use at most two threads, specify the following setting:
-Djet.gc.threads:2
Note: parallel garbage collector is not available in the Standard Edition of Excelsior JET.
Note: information in this section is not applicable to the Standard Edition of Excelsior JET.
New in JET 4.8:
With Excelsior JET, you can optimize disk footprint of your Java application, that is, reduce the amount of disk space required by the application installed on target systems. This can be useful if the application files should be placed into flash memory, which is a typical requirement for contemporary embedded systems. Another use case is running a Java application off a USB flash drive without installation.
Excelsior JET includes the Global Optimizer that performs static analysis and uses the profile information collected during Test Run to figure out what application and library classes are rarely used or not used at all during execution.
The idea behind the saving of disk space is not to compile the classes that will unlikely be loaded at run time: such class files are compressed when creating the installation package and then installed in a compressed form on the target system. This technique helps reduce disk footprint dramatically with a minimal impact on application start-up time and performance in most cases.
If, however, the application tries to load a class placed into the compressed bundle, the JET Runtime inflates (a part of) the bundle to access the requested class transparently to the running application. This technique is called on-demand decompression.
There is a trade-off between the effectiveness of disk footprint reduction and possible overheads that on-demand decompression may impose. You have two options to balance the overheads as described below.
The medium reduction method saves up to 15 MB of disk space. If on-demand decompression occurs, the JET Runtime inflates only a part of the compressed bundle to get the requested class file. As a result, this reduction method has little impact on start-up time/performance and does not increase memory usage.
The high reduction method saves up to 30 MB of disk space using so called solid compression. That is, if on-demand decompression occurs, the entire bundle is inflated and temporarily stored to make its contents available to the Runtime.
Note: inflating the highly compressed bundle takes up to several seconds and thus pauses application execution until the data are decompressed. Refer to section On-demand decompression that describes how to achieve non-disruptive execution.
Two techniques of storing the uncompressed data are implemented:
You can choose the method of disk footprint reduction appropriate to your application using the JetPackII tool. When creating the installation, select the desired options in the Disk footprint panel on the Runtime page.
In addition to enabling the compression of unused classes, you may exclude optional components of the JET Runtime from the resulting installation (see Step 4: Configuring the JET Runtime.)
Another possibility is tuning the compiler options that control the executable size. The major effect can be achieved by setting the "Low" or "Tiny methods only" policy for the inlining optimization (see Method inlining for details.)
These methods help you further reduce disk footprint of your optimized Java applications.
If you opt for the high reduction of disk footprint, on-demand decompression of the entire bundle may occur during application execution. Note that it happens only if the Global Optimizer could not detect all classes that are used at run time and some of them were placed into the compressed bundle when creating the installation.
Before deployment of your application to target systems, you can check whether the decompression occurs at run time. For that, test your application launched from within JetPackII on the page Trial Run. If the decompression has occurred, JetPackII displays a warning after completion of the trial run.
If you want to eliminate the decompression overheads, you should assist the Global Optimizer by providing a more complete profile information. To do that, open the project in the JET Control Panel and perform the test run step to repeat the same testing scenarios you used when running the application from within JetPackII.
Moreover, if there are automatic tests for the application, e.g. code coverage or stress tests, you can perform the test run without invoking the JET Control Panel as described in section Performing a Test Run.
As a result, the profile information will be automatically completed and you can then re-compile your application with the Global Optimizer enabled. To learn more about why the test run is required, refer to section Why Test Run is necessary.
If, due to some reasons, the performing of a exhaustive test run is not feasible for your application, you can select the medium reduction method to avoid possible overheads of on-demand decompression.
Note: information in this section is not applicable to the Standard Edition of Excelsior JET.
You can create a trial version of your Java application that will expire in a specified number of days after the build date of the executable or on a fixed date /The setting of fixed date expiration is available only though the command line compiler./ . It means that you will need to update the download file of your application from time to time. In return, the end user will not be able to bypass the license check by simply changing system date at install time. As the evaluation period is over, the application no longer starts and shows the expiration message you specified when compiling it.
You enable creation of the trial version as follows:
-EXPIRE=number-of-days
or
-EXPIRE=DayMonthYear
For example, you may add to the project file equation
-EXPIRE=60
to create a two month trial version; or equation
-EXPIRE=15Oct2008
to enable expiration of the trial version on the date October 15th 2008.
To specify the expiration message do the following:
-EXPIREMSG=expiration-message-text
You may use the control sequence \n in the message to display the following text on a new line.
To customize appearance of your application, you can
You may control these features at compile time using either JET Control Panel or command line interface to the JET compiler as described below.
To associate an icon with the resulting executable, do the following.
!module path-to-the-icon/MyApp.ico
to the end of the project.
By default, the standard input/output/error streams are enabled to let the application print messages to the console. As a result, when starting your GUI application, you see a black console window opened in addition to the application’s frames. If you do not want the window to appear, you can suppress it /In Sun JDK, you would use the javaw launcher for that./ for the application:
-GUI+
If startup of your application takes longer than you would like it to do, the thumb rule is to show a splash screen. It definitely relieves the loading process from the end user’s perception, moreover, the splash may contain information about your product and company.
The splash screen functionality appeared in Java API since Java SE 6. For more details, see
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/splashscreen
Excelsior JET extends that functionality as follows:
All you need to do is to specify the necessary splash settings to the JET Runtime.
If the splash image has been specified in the manifest of the appllication’s JAR file, the respective image will be obtained automatically:
-splashgetfrommanifest+
Otherwise, you need to assign the application a splash screen image manually:
-splash=path-to-the-image-file/MySplash.gif
The set of supported image formats depends of the active profile (see Profiles):
You may convert images to required format using a third-party image processing tool.
Once assigned, the splash will quickly appear at the very startup of the application (hence the name InstantSplash.)
There are various options to control when the splash screen image shall disappear.
An obvious behavior of the splash screen is to disappear when the main application’s window is opened. However, it is less obvious how to determine what window is the main one (consider an application that opens auxiliary windows such as console, list of warnings, or some dialogs before the main window.) You may choose one of the following "auto-hide" policies:
Note: If you opted for this behavior and did not suppress the console window for your application (see
Console window), the splash screen disappears when the console is opened. If this behavior is not desirable, choose another policy to resolve the issue.If you want to change the default policy, do the following:
-splashcloseonawtwindow-
-splashcloseontitle="My main window"
-splashcloseonawtwindow+
Another option that controls the splash screen behavior is a splash delay. You may wish to delay splash disappearance, e.g. to let the user enjoy your artwork. For that, specify the number of seconds you want it to stay on the screen:
-splashmintime=3
Note: The splash delay does not work if you opted to hide the splash screen when any AWT window opens. In that case, the Show splash for box is disabled and the SPLASHMINTIME equation is ignored.
If a delay is set, the splash works as follows. It appears at application startup and stays on the screen for the specified time. After that, the selected "auto hide" policy has effect. If the window has been already opened, the splash disappears; if not, it remains on the screen until the respective window will be opened.
Finally, you may choose whether to hide the splash screen if user clicks on it. By default, user click hides the splash screen for Java 5 applications, but does nothing for Java 6 applications. If you wish the splash screen to disappear on user clicks for Java 6 applications as well, do the following:
-SPLASHCLOSEONCLICK+
By default, Throwable.printStackTrace() methods print a few fake elements, because stack tracing is disabled in the JET Runtime. However, some third-party APIs may rely on stack trace printing. One example is the Log4J API that provides logging services.
The JET Runtime supports two modes of stack trace printing: minimal and full. In the minimal mode, line numbers and names of some methods are omitted in call stack entries, but class names are exact. In some cases, it is enough for stack trace-dependent APIs to work, e.g. the Log4J API operates flawlessly in this mode.
Note: Enabling stack trace may negatively impact performance, if exceptions are thrown and caught repeatedly.
In the full mode, the stack trace info includes all line numbers and method names. However, enabling the full stack trace has a side effect of substantial growth of the resulting executable size by approximately 30%.
In the JET Control Panel, you enable stack trace on the Target page (see Stack trace support).
You may also select the stack trace mode via compiler options and run-time properties. To enable the minimal stack trace, set the property jet.stack.trace:
-Djet.stack.trace
To enable the full mode, in addition to setting the property, toggle the GENSTACKTRACE option ON in your project file
+GENSTACKTRACE
and re-compile your application.
For security reasons, you may wish to completely disable stack trace output in the end-user version of your application. To do that, set the option DISABLESTACKTRACE ON in your project file:
+DISABLESTACKTRACE
In a JVM, assertions are disabled by default, but may be enabled for the entire application or for particular classes at launch time using the java command’s switches -ea, -da, -esa, and -dsa. With JET, if you enable assertions using the same switches in the JETVMPROP equation in your project file:
-JETVMPROP=-ea:com.MyCompany.MyPackage
or control them at launch time using the JETVMPROP environment variable:
SET JETVMPROP=-ea:com.MyCompany.MyPackage
MyApp.exe
JET also supports enabling and disabling assertions programmatically at run time.
A typical Java application consists of classes that contain the application’s code, and resources such as images, icons, property files, which the application loads at run time.
If the resource files are placed into one or more jar files, the compiler packs the resources into the resulting EXE or DLL, almost like that is done for native applications. The JET Runtime will read the resource files during execution and use them as if they were separate files. No changes in your application’s code are required to make this technique work.
Using the JET Control Panel, you may enable/disable resource packing for particular jars as described below.
When compiling a Java application, the JET Optimizer processes each jar file listed in the classpath and, depending on the project settings, may pack the contained resource files into the resulting executable.
For jar files, the Optimizer supports the following resource packing modes:
This is the default mode for the jar files included in the project.
For example, suppose you develop a Java application extensible with plug-ins. You may disable packing the plug-in jars and distribute them along with the executable. As a result, client installation of your application can be updated by replacing the jar files, for example, with newer versions of the plug-ins. Note that the JET Runtime will JIT-compile the classes from the jar files.
For example, consider a Java component whose implementation requires presence of the original class files at run time. For instance, Java Crypto Extensions also known as security providers check the sizes of their class files during execution. In such cases, the class files serve as both program code and resources. Therefore, despite all the classes are pre-compiled, you have to make them available to the running application. Packing such jar files as a whole resolves the problem.
Note: Excelsior JET does not support the packing of resource files that reside in directories. The reason is that directories are writable, that is, the application may overwrite resource files at run time, so packing them into the executable may change behavior of the program.
If your application really overwrites resource files at run time, you should deploy that directory along with your executable and ensure the directory is included in the application classpath. For more details, see Step 3: Configuring Resources And System Properties.
Otherwise, you may place all classes and resources from the directory in a jar file and add it to the classpath. As a result, the JET Optimizer will compile the jar file in the default mode of resource packing as described above.
To change the default settings, open your project file with the JET Control Panel, and go to the Classpath page. The central area of the page is occupied by the classpath grid. Each row of the grid corresponds to a single classpath entry — a directory or jar file. The last column named Pack into exe, specifies the resource packing mode for each entry. Click the cell, and select the appropriate value from the drop-down list.
If you edit project files manually, use the PACK equation to control resource packing. Refer to the JC reference chapter for more details.
When creating a profile, JET precompiles the Java SE classes that are needed for input and output of characters in national encodings into a set of DLLs. The idea is to place support for rarely used encodings and encodings that require large conversion tables (such as Chinese) into separate DLLs, so as to reduce the disk footprint of compiled applications that do not use some or all of those encodings.
If your application may need to use national encodings, make sure to include the respective locales into the installation package as described in Selecting optional components.
On a virtual machine, if a certain class is imported but never used during program execution, i.e. it is never instantiated, none of its static methods are called, and none of its static fields are accessed, then no attempt to load that class would occur and therefore the program would execute normally even if the respective class file is not present on the system or cannot be reached by the VM.
Similarly, if a class does not contain a particular method or field that is referenced in another class, execution on a virtual machine would fail only when and if control reaches the code referencing that absent field or method.
Being an ahead-of-time compiler, Excelsior JET analyzes the entire compilation set and thus is able to detect such inconsistencies. By default, they result in compilation errors. However, when an inconsistency is detected in bytecode that is not under your control, such as a third-party class library, you usually do not have a chance to remedy it quickly. If you encounter such problem, contact the vendor who supplied the inconsistent bytecode, and toggle the respective JET options to make the compiler treat bytecode inconsistencies as warnings:
+IGNORECLASSDUPLICATION
-CLASSABSENCE=HANDLE
+IGNOREMEMBERABSENCE
The compiler will report warnings and will insert the code throwing java.lang.NoSuchMethodError or java.lang.NoSuchFieldError for all locations where absent members are used.
Note: In some applications, imported classes unavailable at compile time become available at run time. JET may handle this situation properly if you enable the reflective shield facility of the Mixed Compilation Model.
In some cases, the main JET compiler may fail to compile a particular method due to lack of memory or inability to restore the method’s high-level structure required for optimizing compilation, which may be caused by bytecode obfuscation. To cope with it, the main compiler invokes the so called baseline compiler for such methods. The baseline compiler implements only a few simple optimizations, and thus is able to compile any verifiable bytecode.
If the baseline compiler was invoked at least once during compilation of your project, the main compiler issues a message about the number of methods processed by the baseline compiler. Additionally, it logs the information about the methods compiled with a lower optimization level. The log file, having the executable’s name and the ".vaz" extension, is created in the current directory.
If baseline compilation occurs during compilation of your project, we would appreciate if you e-mail us the resulting ".vaz" log file along with the .class files listed in it. Doing that, you help us improve the quality of our product.
A JET Runtime crash, that is, an abnormal termination of application execution may be caused by bugs in the Runtime or in the application itself. The latter typically occurs due to misuses of JNI functions from within native method libraries that come with certain third-party components or APIs. Such errors are hard to diagnose because a poorly coded native method can corrupt application memory structures in any way.
If this happens on the developer system, the Runtime prints some error information followed by the message
Please contact Excelsior Support Dept. at java@excelsior-usa.com
If, however, the application terminates due to a Runtime crash on end user systems, the tail message will be replaced with
Please contact the vendor of this application
You can customize this message to print, for example, a contact information of your company’s customer service. To do that, set the system property
jet.runtime.error.message=message-text
when compiling or packaging your application (see How to set system properties). You may use the \n control sequence in the message to display the following text on a new line.