Brought to you by EarthWeb
ITKnowledge Logo Login Graphic Y2K problems?Click here
Y2K problems?Click here
ITKnowledge
Find:
 
EXPERT SEARCH ----- nav

EarthWeb Direct

EarthWeb sites: other sites

Previous Table of Contents Next


Various JVM Implementations

Each JVM is a little different. Knowing the various nuances is vital to development and required knowledge for the Certified Programmer Examination.

Not all computers are created equal. Likewise, not all JVMs are created equal. You have seen, through the discussion of the JVM and the Class file execution, that the JVM specification leaves room for implementation characteristics. An example is the issue of garbage collection. The JVM makes no assumptions about how unused memory resources are reallocated and placed for reuse. Issues such as these are responsible for differences in cross-JVM operation characteristics.

Garbage collection, threads, and GUI characteristics are, for Java developers, the things that go “bump” in the night. In later chapters, you will look at the threads and GUI cross-JVM implementation issues. This chapter has discussed the concept of garbage collection, but the intrinsic scheduling problem of garbage collection might not be obvious. For example, say your applications are providing some sort of real-time information, but you are having a problem. Every so often, your application stops responding for a period of time, and then comes back to life. This problem is the direct responsibility of JVM-implementation garbage collection.

Not all JVM-implementation characteristics are as obvious as your application not working. Fortunately, the JDK test suite has eliminated a large number of problem spots that plagued earlier Java development.

JDK Test Suite

Beginning with JDK 1.1, Sun has required Java runtime environment implementations to conform to the JDK Test Suite. That is, in order for a product to claim that it is “Java-enabled”, it must first pass the JDK Test Suite. This initiative by Sun provides a standardization of the various Java runtime environment implementations.

Before JDK 1.1, all vendors that offered Java runtime environment support took it upon themselves to broadly interpret the JVM specifications. Specifically, issues like cross-platform thread support and GUI presentation were areas with high degrees of variation. The result was non-predictable class execution on the various runtime implementations. A quick example of this is exemplified in Windows 3.1 thread support: there is none!

The JDK Test Suite has done wonders for cross-platform implementations. Sun has also stated their dedication to ensuring conformity through licensing restrictions. If you don’t conform, you don’t get to use the word “Java” in your product. This is not to say that now all JVMs will be created equal, but at least they will be from the same planet.

Cross-Platform Issues

Maintaining a list of all cross-platform issues is impossible for a couple of reasons. The first reason lies in the fact that the list of platforms is in a constant state of flux. It seems as if every day news of a new Java-enabled device is hitting the streets, with no end in sight. The second reason for being unable to provide a complete list has to do with the rate of change in the Java world. New technologies are added and others deleted almost daily. This being the case, knowledge of platform-specific issues is not required on either certification exam. Nevertheless, it is invaluable information.

The following list provides some basic Java execution characteristics for a handful of platforms. Platforms excluded from this list are no less important than included entries. Rather, the included platforms simply provide the largest range of Java-enabled platforms.

  Window 95 /Windows NT—Despite differences in display characteristics between the various browsers, Java support is relatively stable. However, garbage collection is usually performed only when all system resources are exhausted, and thread scheduling can cause a starvation state.
  Window 3.1—This platform has the same issues as Windows 95/Windows NT; however, threads are not supported on the 16-bit implementation.
  Macintosh—The major complaint for most Macintosh developers is the foreign look and feel of Java GUI elements. That is, buttons, scrollbars and other GUI elements have a PC look and feel.
  Various UNIX flavors—Probably the widest array of compatibility issues can be seen in the UNIX world, specifically with respect to thread scheduling. Remarkably enough, GUI presentation is relatively stable across all X-window implementations.
  JavaChips—JavaChips are silicon-based implementations of the Java Virtual Machine. Although a number of manufacturers are ramping up to provide these chips, it is too soon to note any operating characteristics.


Previous Table of Contents Next
HomeAbout UsSearchSubscribeAdvertising InfoContact UsFAQs
Use of this site is subject to certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.