Diagnosing Java code: Platform Dependencies "gotcha problem"

Write once and run anywhere. This is a promise, but the Java language can sometimes not do it. Admittedly, the JVM has raised the level of cross-platform interoperability to unprecedented heights, yet a small flaw in the specification and implementation level makes it impossible for programs to behave correctly on multiple platforms.

One of the main advantages of using Java programming is that it gives you a great degree of platform independence. You can just compile your product into bytecode and distribute it to any platform with a JVM without having to build a separate build for each target platform. Or at least that's the way it should be.

But it's not that simple. Although Java programming can save developers countless time with multi-platform support, there are many compatibility issues between different JVM versions. Some of these issues are easy to find and correct, such as using platform-specific delimiter characters when constructing path names. But other problems may be difficult or impossible to intercept.

It is therefore important to remember that some of the unusual procedural behaviors that are difficult to interpret may be an error in a particular JVM.

Vendor-related errors

Of course, if you want to look at some of the many subtle platform-related errors that exist in the JVM, you only need to check the Sun's Java Bug Parade (see Resources). Many of the errors listed here apply only to the implementation errors of the JVM on a particular platform. If you happen to not be developing on the platform, you may not even know that your program will be blocked on that platform.

However, not all Java platform dependencies are the result of JVM implementation errors. Significant platform dependencies are the result of the JVM specification itself. When the details of the JVM are unrestricted at the specification level, vendor-related behavior can arise between JVMs.

For example, as we reviewed "improve the performance of your Java Code" (May 2001), the JVM specification does not require optimization of tail-recursive calls (Tail-recursive call). A tail recursive call is a recursive method call that appears as the last action of a method. More generally, any method invocation, whether recursive or not, as long as it appears at the end of the method is the tail call (tail called). For example, consider the following simple code:

Listing 1. A factorial of the tail recursion

public class Math {
　 public int factorial(int n) {
　　 return _factorial(n, 1);
　 }

　 private int _factorial(int n, int result) {
　　 if (n <= 0) {
　　　 return result;
　　 }
　　 else {
　　　 return _factorial(n - 1, n * result);
　　 }
　 }
}

In this example, both the public factorial method and the private helper method _factorial include a tail call, factorial contains a tail call to _factorial, and the _factorial contains a tail recursive call to itself.

If you think writing factorial in this way is especially complicated, you're not the only one with that feeling. Why not write it in a much more natural form than the following?

Listing 2. A factorial of pure recursion

public class Math {
　 int factorial(int n) {
　　 if (n <= 0) {
　　　 return 1;
　　 }
　　 else {
　　　 return n * factorial(n-1);
　　 }
　 }
}

The answer is that the tail recursion takes into account a very powerful optimization--tail recursion lets us replace the stack frame built by the main tune method with the stack frame built for the method being modulated. This can greatly reduce the stack depth at run time, thus avoiding stack overflows (especially if the tail call is recursive, such as the tail call to _factorial in Listing 2).

Some JVMs implement this optimization; As a result, some programs can cause stack overflows on some platforms, not on other platforms. If this optimization can be done statically, we can only compile the bytecode into the form of the tail call, so that we can enjoy both platform independence and this optimization. Unfortunately, this optimization cannot be done statically, as I have explained in the article on this topic cited above.