The core requirement for the JVM is that it must be compatible with Java 8.
Each FWD component (conversion, application server, client, user-defined functions running at the database) can use a different JVM. These can run on the same system or different systems. They can even run on a different operating system platform. There is no dependency between JVMs of different components, since they are separate operating system processes.
The following JVM versions have been well tested:
- Oracle JDK 1.8 on Linux
- Oracle JDK 1.8 on Windows
- OpenJDK 1.8 on Linux
- OpenJDK 1.8 on Windows
The specific versions of Oracle JDK 1.8.0_101 and OpenJDK 1.8.0_111 have both been tested and have been found to work well. Generally, it is safe to use any later version of the Java 1.8 platform.
The client does not generate Java code at runtime, which means that it is possible to use a JRE (runtime only, no development kit) instead of a JDK.If your ABL application is using calls to native libraries, then the bitness of the installed JVM must match the bitness of these native libraries. You will not be able to execute calls into a 32-bit compiled native library from a 64-bit JVM or 64-bit native code from a 32-bit JVM.
If the legacy application is not dependent on native library calls, and if your operating system is 64-bit architecture, you may use either the 32-bit or the 64-bit JVM. On a 32-bit platform, only a 32-bit JVM is possible.
The application server process (JVM) is where the majority of working memory exists for each client (accessing the system). The actual memory used will depend on the queries, the block flow, recursion and other features of the original ABL. The converted application code is actually running in the common server process, which is different from how Progress ABL works.
By default, we recommend using the 32-bit JVM on the client for the following reasons:
- The thin client does not need large amount of memory to run, this means that the heap can (and should) be limited in size.
- The client does not process any data except for the displaying primitives received from server and any file-system or other OS related calls (which map to ABL features). The improved performance of a x64 built JVM is insignificant.
- All things being equal, the memory footprint is greater on a 64-bit JVM as the pointers are twice as long as the pointers in a 32-bit JVM. Java uses pointers intensively as all references to objects (except for the scalars) are in fact pointers. This leads to the fact that a 64-bit JVM takes between 40% and 50% more memory on average than a 32-bit JVM.
Using the 32-bit version will greatly reduce the memory footprint and overhead of each JVM instance. On client systems where there will be large numbers of JVM instances (often at least one per user), this can accumulate into a significant savings.
From a heap perpective, the FWD Client needs enough memory to handle its windows, frames, widgets, streams and other ABL resources (and their contained data). These can be used in a deeply nested manner, which means that some programs can create many such resources simultaneously. However, even in such a case the memory requirements of the client tend to be quite limited.
For the above reasons, there is no strong requirement for the 64-bit JVM. Using a 32-bit JVM for this purpose will be faster and will use less memory. Use a 32-bit JVM if possible. Even applications with deeply nested UI processing can usually be run with max heaps of 16MB to 32MB.