This section describes how to migrate Java applications developed on another JDKs to the Oracle JRockit JDK to ensure optimal performance during runtime. This section contains information on the following subjects:
Migrating an application to the JRockit JDK is a relatively simple process, requiring some minor environmental changes and following some simple coding guidelines. This section provides instructions and tips to successfully completing this simple process. It also describes some of the benefits and possible problems you might encounter during migration and it discusses some best J2SE coding practices for you to follow to ensure that your application runs successfully once it is running on the JRockit JDK.
The JRockit JDK is the default JDK shipped with Oracle WebLogic Server. Although there are other JDKs available on the market today that you can use to develop Java applications, Oracle recommends that you use JRockit JDK with your Oracle products.
Migration is available for all platforms when Oracle WebLogic Server is supported with the JRockit JDK. For a list of supported platforms, please refer to:
Should you experience any problems or find any bugs while attempting to migrate an application to the JRockit JDK, please send us an e-mail at firstname.lastname@example.org. We would appreciate if you could provide as much information as possible about the problem, for example:
This section describes basic environmental and implementation changes necessary to migrate to JRockit JDK from a third-party JDK, such as the Sun Microsystems JDK. It includes information on the following subjects:
|Note:||The changes described in this section apply primarily to Oracle WebLogic Server. If you are working with other Java applications, you will need to change the scripts and environments according to how that application is set up.|
To migrate from a third-party JDK to the JRockit JDK, you need to make the following changes to the files.
JAVA_HOMEenvironmental variable in
.sh) to the appropriate path.
JAVA_VENDORenvironmental variable in
-XX:NewSize). If possible, replace them with Oracle JRockit JVM-specific options; for example,
-Xns. Other flags that might need to be changed include
config.xmlto point the default compiler setting(s) to the
javaccompiler in the JRockit JDK.
For information on other coding practices that will ensure a successful migration of your application to the JRockit JDK, please refer to.
Once you’ve migrated your application to the JRockit JDK, you might want to tune the JVM for optimal performance. For example, you might want to specify a different start-up heap size or set custom garbage collection parameters. You can find detailed information on tuning the JRockit JVM in the chapters of the section Profiling and Performance Tuning.
The non-standard options, that is, options preceded with
-X, are critical tools for tuning a JVM at startup. These options change the behavior of the JRockit JVM to better suit the needs of different Java applications.
While all JVMs use non-standard options, the option names might not be the same from JVM to JVM; for example, while the JRockit JVM will accept the non-standard option
-Xns to set the nursery in generational concurrent and generational parallel garbage collectors, Sun’s HotSpot JVM uses the non-standard option -
XX:NewSize to set this value.
If you are migrating an application to the JRockit JDK, we recommend that you become familiar with the non-standard options available to you. For more information, please refer to the.
You should also be aware that, being non-standard, non-standard options are subject to change at any time.
Always test your application on the JRockit JVM before putting it into production. If you develop your application on the Sun JVM (HotSpot), you must test your application on the JRockit JVM before you put it into production.
Some important reasons for testing are:
To test your application on the JRockit JVM:
The following J2SE tools, normally available with the Sun JDK, are not shipped with the JRockit JDK:
The JRockit JDK provides internal tools that are equivalent to or better than most of the Sun tools. Listing 5-1 lists the Sun tools and their JRockit JDK equivalents. Some of these tools require using the
jrcmd feature. For more information, please refer to
JRockit Memory Leak Detector (see The JRockit Memory Leak Detector)
This section describes the compatibility between command-line options available when running the JRockit JVM and when running the Sun Hotspot JVM. These options correspond to each other by name only, by function only, or both by name and function.
Table 5-2 lists options that both Sun Hotspot JVM and the JRockit JVM have but have different functionality depending upon the JVM you are running.
Sets the initial and minimum size of the heap. For complete description, please refer to
Table 5-3 lists options that work the same or similarly on both Sun Hotspot and the JRockit JVM but have different names depending upon the JVM you are running.
Table 5-4 lists options only available when using the Oracle JRockit JVM.
The migration tips discussed in this section represent an evolving list. Often, a successful migration to the JRockit JDK depends as much upon the application being migrated as it does to the VMs being used. Oracle welcomes suggestions based upon your experiences with migrating applications to the Oracle JRockit JDK. Feel free to submit any migration ideas or comments to the Oracle JRockit forums at.