Volume Number: 14 (1998)
Issue Number: 5
Column Tag: Javatech

Writing Java on the Mac for All Platforms

by Ken Ryall

Here are several of the pitfalls of writing multi-platform Java code

It's easier than ever to write your Java code on the Mac for multi-platform use. You can write once on the Mac, then run anywhere, but you'll learn a lot about the way Java is implemented on each platform along the way.

Ironically, the Mac is a good Pure Java starting point. If it works on the Mac it should work on other Java platforms. However, there are differences, often subtle ones. These differences between Java on the Mac and Java on other platforms are often reflections of each underlying operating system. In addition to differences in how each virtual machine is implemented, other potential problem areas include threads, networking, file systems, and user interface elements.

Unlike most other Java platforms, Macintosh Java uses cooperative threads rather than preemptive ones. Java's preemptive threads are simulated on the Mac by a cooperative VM. It will yield time to other Java threads and to the Mac OS when a Java thread's state becomes "not runnable". This happens when a thread is waiting for I/O to complete, is put to sleep, is suspended and in a few other cases.

This difference in underlying thread implementation means you should avoid making assumptions about thread scheduling, priority or timing beyond what is specified in the Java API. Threads of equal priority will get very different treatment depending on the VM.

Also, be aware of what kind of code will let the VM run other threads. For example, when opening a socket and listening for connection requests, the VM will run other threads while waiting for Socket.accept() to return a connected socket.

// bind a socket on port 3000
ServerSocket mySocket = new ServerSocket(3000);
// listen for connection requests
Socket clientSocket = mySocket.accept();

However, the loop below contains no calls to I/O and may block other threads on the Mac. On platforms such as Windows NT other threads would still be allowed to run.

int count = 5000000; // busy pointless loop
while (count > 0)
   count -; // While in loop VM may run other threads, maybe not.

If you have CPU intensive loops like this you'll need to call Thread.yield() to allow the VM to service other threads.

If your application uses threads in more than a casual way you'll need to experiment to find best cross-platform performance. For example, here is a thread with an idle loop that checks things now and again and shares time with other threads by calling Thread.yield():

public void run()
{
   boolean keepGoing = true;
   while(keepGoing)
   {
      // do some stuff...
      // yield time to other threads
      yield();
   }
}

Calling Thread.yield() while looping seems to work fine on the Mac. However, on Windows NT constantly calling Thread.yield() will leave the VM hogging as much of the CPU time as it can get. Putting the thread to sleep for short periods is a better cross platform solution.

public void run()
{
   boolean keepGoing = true;
   while(keepGoing)
   {
      // do some stuff...
      // sleep for ten seconds, this will let other threads run
      sleep(1000 * 10);
   }
}

Developing on the Mac will also make you keep your use of threads simple: more than a few running Java threads hurts performance more than on other platforms.

The network classes in the java.net package use whatever native TCP/IP services the host machine offers. This means your Java networking code will pick up any eccentricities in the native libraries. A common complaint of cross platform Java developers is that their network sockets work with one platform/VM combination but not another. Results can even vary from machine to machine and network to network.

Networking problems can include socket/stream combinations that don't return all the data until asked multiple times. Other sockets don't seem to want to send their data until closed, even after being flushed.

In one case, my server was returning some data by writing to a stream and closing the socket. This worked fine on Mac OS and Windows NT but sent empty packets from some Windows 95 machines on some networks. The fix? Insert a tiny delay between flushing the stream and closing the socket. How did I find it? Desperate trial and error.

Most of these problems are related to bugs in the various VMs, whose intensive revision has produced evolving levels of functionality and stability. Reviewing some of the many Java networking examples can help identify problems and workarounds. In particular, the web server Jigsaw http://www.w3.org/jigsaw/ is a good example of a complex multi-threaded application. Jigsaw works cross-platform and has undergone more extensive testing than most examples available.

Java includes cross-platform classes for handling files and tries to present a platform neutral API, but it helps to remember that the whole thing came from the Unix world. Nowhere is this more apparent than in the way the File class works. In fact, the Java File class probably creates more cross-platform problems than any other because of its assumptions about the native file system.

To begin with, file names can be longer than the 31 characters that the current Mac file system allows. ( HFS+ supports longer file names internally, but there isn't an API to access them yet.) Lots of Java sample code that has never seen a Mac has files like: "MyReallyCoolJavaThreadedNetworkingClass.java". VMs on the Mac have no problem with longer names in JAR files, you just can't have the original source files. This can be a problem if you're working with developers on other platforms who like very long file names. Until the long filenames in HFS+ are accessible, you'll either have to get them to be less verbose, or build their work into libraries so you won't have to work with their source files directly.

Various VMs also make different assumptions about case-sensitivity of file names and allowable characters in file names. Remember that most virtual machines began life as Unix source code and may be incompletely ported to their new native file systems.

In Java, files are specified by path name, but trying to build a path name in a platform neutral fashion is difficult because VMs return inconsistent and conflicting values for descriptions of parent directories and separator characters. Making a path name that will work with one VM isn't too difficult, making one that is cross platform friendly is often much more difficult.

Cross platform Java developers are frustrated by this and usually try to simplify file specification so they don't have to build path names. If you do, be sure to use File.pathSeparator() instead of hard coding a path separator. Also, examine your file naming schemes and remove characters that aren't allowed on any of your target platforms.

Differences in platform user interface mean that a some of your interface may not come out looking like you intended. Fortunately you can often tweek placements, sizes etc. in a platform neutral way, you'll just need to try out the results on each of your target platforms as you go. Be sure to use layout managers, not absolute locations, to place items and avoid assumptions about things like font metrics and screen size.

Also, every VM on every platform has its own AWT bugs and display glitches, and these change as the VMs are revised. Most of these you'll be able to see and work around.

Don't forget that while you can write a lot of pure java cross platform code, you can still determine what platform is running your Java code and act accordingly.

      String whichOS = System.getProperty("os.name");
      if (whichOS.contains("Mac"))
      {
         // do mac specific stuff here
      }

Testing cross-platform Java applications is simple if tedious; you just have to try it with every VM/platform combination you hope to use it with. In particular, exercise the features that use networking, threads, and deal with files. Check the UI carefully for missing elements and overlapping items.

Some of the Java tools are less mature than their C++ equivalents so there aren't as many debuggers and other testing utilities to work with. Of course, there is the old fashioned way: System.out.println(). Finding out how things work with virtual machine X on platform Y is mostly a matter of trial and error.

It's also helpful to find other developers who are sharing their experiences with the VMs you are targeting. For Mac VMs a good place to start is the MRJ mailing list at http://www.lists.apple.com/mrj.html and there is also the Metrowerks newsgroup at news://news.metrowerks.com/comp.sys.mac.programmer.codewarrior.

Java's platform independence quickly vanishes when its time to install and launch your application. Each platform has its own VM installation and method for launching a Java application. If you want to look just like any other professional application you'll need to build an installer for each platform that includes a VM and puts all your pieces where you want them: maybe the "Startup Items" folder on the Mac or as a service on NT.

This can be complex and tough to maintain, but is no worse than installing a complex cross platform C++ application. A more Java-oriented solution is InstallAnywhere, available from Zero G Software http://www.zerog.com. InstallAnywhere is written in Java and lets you build an single universal installer that will work on any platform, including setting the runtime environment, and installing a VM.

Developing cross platform Java code on the Mac really works if you'll keep a few things in mind. You can write once and run anywhere as long as you test and make a few adjustments. Finding solutions to cross-platform problems will often reveal problem code that slipped by the original complier or VM and needs to be reworked anyway. If you'll willing to deal with a few platform-specific problems and a wider variety of VM behavior, you'll have the satisfaction of developing your code on the Mac, and the ability to drop the result on an NT machine and find that it all just works.

Ken Ryall, kryall@outer.net, has been developing on the Mac since 1985 and is currently working on the debugger at Metrowerks in Austin, TX. When not at work he's usually out flying or at home trying to convince his border terrier not to chew up the ISDN line again.