Migration Guide

Migrating to WebLogic JRockit

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:

About Application Migration

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.

Why Migrate?

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.

Migration Restrictions

Migration is available only for Intel-based Windows systems and Linux systems. For a list of supported platforms, please refer to:

http://download.oracle.com/docs/cd/E13188_01/jrockit/docs81/certif.html

Migration Support

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 support@bea.com. We would appreciate if you could provide as much information as possible about the problem, for example:

Hardware
Operating system and its version
The program you are attempting to migrate
Stack dumps (if any)
A small code example that will reproduce the error
Copies of any *.dump and *.mdmp files (*.mdmp files are available only on Windows)

Migration Procedures

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:

Environment Changes

To migrate from HotSpot (or any third-party JVM) to WebLogic JRockit JVM, you need to make the following changes to the files.

Set the JAVA_HOME environmental variable in <WEBLOGIC_HOME>/common/commEnv.cmd (or .sh) to the appropriate path.
Set the JAVA_VENDOR environmental variable in <WEBLOGIC_HOME>/common/commEnv.cmd (or .sh) to BEA.
If you are using a start-up script, remove any Sun-specific (or other JVM provider) options from the start command line (like -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.
Change config.xml to point the default compiler setting(s) to the WebLogic JRockit javac compiler.

Other Tips

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.

Tuning WebLogic JRockit JVM for Your Application

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.

You should also be aware that, being non-standard, non-standard options are subject to change at any time.

Testing the Application

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.

Why Test?

Some important reasons for testing are:

Sometimes you might find bugs in your own program that don't occur on the Sun JVM; for example, synchronization problems.
You might have used third party class libraries that are not 100% Java and rely on Sun-specific classes or behavior.
You might have used third-party class files that are not correct. WebLogic JRockit has been known to enforce verification more rigorously than the Sun JVM.

How to Test

To test your application on WebLogic JRockit:

Run your application against any test scripts or benchmarks that are appropriate for that application.

If any problems occur, handle them as you normally would for the specific application.

Submitting Migration Tips

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:

jrockit.developer.interest.migration