This section describes how to migrate Java applications developed on another JVM to WebLogic JRockit so that they perform to their optimal capability when running on BEA WebLogic Server. It contains information on the following subjects:
Migrating an application to BEA WebLogic JRockit JVM 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 WebLogic JRockit.
BEA WebLogic JRockit JVM is the default JVM shipped with BEA WebLogic Server. Although there are other JVMs available on the market today that you can use to develop Java applications, BEA Systems recommends that you use WebLogic JRockit JVM as the production JVM for any application deployed on WebLogic Server.
Should you experience any problems or find any bugs while attempting to migrate an application to WebLogic JRockit 8.1, 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:
*.mdmpfiles are available only on Windows)
This section describes basic environmental and implementation changes necessary to migrate to WebLogic JRockit JVM from Sun Microsystems HotSpot JVM or any other third-party JVM. It includes information on the following subjects:
JAVA_HOMEenvironmental variable in
<WEBLOGIC_HOME>/common/commEnv.cmd(or .sh) to the appropriate path.
JAVA_VENDORenvironmental variable in
<WEBLOGIC_HOME>/common/commEnv.cmd(or .sh) to
-hotspot). If possible, replace them with WebLogic JRockit-specific options; for example,
-jrockit. Other flags that might need to be changed include MEM_ARGS and JAVA_VM.
config.xmlto point the default compiler setting(s) to the WebLogic JRockit
For information on other coding practices that will ensure a successful migration of your application to WebLogic JRockit JVM, please refer to Best Coding Practices for JVM Migration.
Once you've migrated your application to WebLogic JRockit JVM, 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. For more information on tuning WebLogic JRockit JVM, please refer to the Tuning WebLogic JRockit 8.1 JVM.
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 WebLogic 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 WebLogic JRockit JVM will accept the non-standard option
-Xns to set the nursery in generational concurrent and generational copying garbage collectors, Sun's HotSpot JVM uses the option -
XX:NewSize to set this value.
If you are migrating an application to WebLogic JRockit, we recommend that you become familiar with the non-standard options available to you. For more information, please refer to Appendix A: Command Line Options by Name, in Tuning WebLogic JRockit 8.1 JVM.
Always test your application on WebLogic JRockit JVM before putting it into production. If you develop your application on the Sun JVM (HotSpot), you must test your application on JVM before you put it into production.
The migration tips discussed in this section represent an evolving list. Often, a successful migration to WebLogic JRockit depends as much upon the application being migrated as it does to the VMs being used. BEA Systems welcomes suggestions based upon your experiences with migrating applications to WebLogic JRockit. Feel free to submit any migration ideas or comments to the WebLogic JRockit SDK migration newsgroup at: