This section contains guidelines for writing applications to run on BEA JRockit. This information provided here is in no way complete; it merely helps you avoid some common pitfalls. BEA Systems does not want to compromise Java's "write once run everywhere" notion. On the contrary, this sections highlights guidelines that are valid for any Java program. They are, however, especially important when switching between JVMs in general and between Sun Microsystem's HotSpot JVM and BEA JRockit JVM in particular.
A BEA JRockit JVM is based on a number of specifications; for example, The Java Virtual Machine Specification and the Java API Specification. You should be aware that many implementations of these specifications exist: BEA JRockit JVM is one. You should never expect any particular behavior that is not specified in one of these documents. Unspecified behavior might differ between the Sun JVM and BEA JRockit JVM. Note too that behavior is sometimes different between individual releases of the Sun JVM and can also change between releases of BEA JRockit JVM.
The specifications are written to give JVM vendors freedom to optimize their JVMs, and therefore they leave certain behavior unspecified. You should understand, however, that numerous parts of the specifications mentioned above are unspecified. The following examples describe three of these unspecified elements.
toString() method of the
java.lang.reflect.Method might include the access modifier
native. Therefore, you should not rely on the result of this call to be equal between JVM implementations. Some classes in the Java API specification are implemented as
native either by BEA JRockit JVM and the Sun JVM. There is no guarantee that a native implementation on one JVM has to be native on another one.
The Java API Specification of the method
defaultReadObject() of the
java.lang.ObjectInputStream class does not specify the order in which fields are de-serialized; hence no such order can be expected.
Finalizers are often error prone since they often implicitly depend on the order of execution. This order differs amongst JVMs, and between consecutive runs on the same JVM. Using finalizers is also inherently bad for performance since it imposes an additional burden on the memory management system that needs to handle execution of finalizers and let objects live longer. For more information on using—and not using—finalizers, please refer to:
Be careful when using
java.lang.Thread.setPriority. Depending on thread priorities might lead on unwanted or unexpected results since the scheduling algorithm might choose to starve lower priority threads of CPU time and never execute them. Furthermore the result might differ between operating systems and JVMs.
The priority set by the
setPriority() method is a parameter that might be used in the thread-scheduling algorithm, which shares CPU execution time between executing threads. This algorithm might be controlled either by the JVM or by the operating system. It is important to be aware of the fact that this algorithm normally differs between operating systems and that the algorithm might change between releases of both the operating system and the JVM. For BEA JRockit JVM native threads, the algorithm is implemented by the operating system.
The classes that BEA JRockit SDK includes fall into package groups
COM.jrockit.*. All but the
COM.jrockit packages are a standard part of the Java platform and will be supported into the future.In general, non-standard packages, which are outside of the Java platform, can be different across JVM vendors and OS platforms (Windows, Linux, and so on) and can change at any time without notice with SDK versions. Programs that contain direct usage of the
COM.jrockit.* packages are not 100% Pure Java.
On BEA JRockit JVM, the current default implementation of
hashCode returns a value for the object determined by the JVM. The value is created using the memory address of the object. However, because this value can be reused if the object is moved during garbage collection, it is possible to obtain the same hash code for two different objects. Also, two objects that represent the same value are guaranteed to have the same hash code only if they are the exact same object. This implementation is not particularly useful for hashing; therefore, derived classes should override
Make sure that you synchronize threads that access shared data. Synchronization bugs often appear when changing JVMs because the implementation of locks, garbage collection, thread scheduling and so on, might differ significantly.
java.lang.System.getProperty(), you should only depend on standard system properties being returned; different VMs may return a different set of extended properties. Non-standard properties should not be returned.
When the JVM starts, it inserts a number of standard properties into the system properties list. These properties, and the meaning of their values, are listed in the Java API specification. Do not expect any other non-standard properties.
When designing applications there is sometimes a choice between running several processes, i.e. JVM instances versus running several threads or thread groups within a single process, i.e. JVM instance. If possible, it is more effective to use as few JVM instances as possible per physical machine.
java.lang.System.gc(). This method behaves differently with BEA JRockit JVM than with other JVMs. Instead of doing a complete garbage collection, as with the Sun JVM and others, when called by an application running with BEA JRockit JVM,
System.gc() behaves depending upon the garbage collector already in use:
System.gc()does a collection in their nursery.
The BEA JRockit JVM garbage collector will generally do a much better job of deciding when to do garbage collection than will
System.gc(). If you are having problems with memory usage, pause times for garbage collection, and so on, you are better off configuring the BEA JRockit JVM memory management system appropriately. See Tuning BEA JRockit JVM in the Tuning BEA JRockit 1.4.2 JVM.