joustlog

I am frustrated about the new AWT SystemTray API that was released as part of Mustang build 38. It has many problems, and even though I discussed these problems with the AWT team before it was released, they have not resolved many of the problems.

I won’t go into all of the problems right now, but I’ll mention a few. First you should look at the SystemTray class and the TrayIcon class.

• Several methods return arrays of TrayIcons and other objects. This is Java 6, a whole release after Java 5, and Sun is still using arrays. Why did we even bother adding generics to Java, if the JDK itself isn’t going to use them?
• This API was designed to provide the lowest common denominator that all platforms support, despite the fact that such API’s have been the subject of a great deal of criticism of Java. I don’t know why Sun is intentionally crippling Java applications. Maybe they are trying to kill Java on the desktop for good. Here are some of the problems:
  • On Mac OS X, “status items” (the equivalent to system tray icons) have a fixed height, but they can have any width. However, there’s no support for this in the SystemTray API, as all icons must have the same size.
  • The displayMessage functionality is not guaranteed to be supported. This is good because OS X status items don’t normally show messages like Windows applications do from tray icons.
    However, there’s no way for your application to know whether displaying a message is supported on the current platform. I expect a lot of if (System.getProperty("os.name").contains("Mac")) {..} in conjunction with the System Tray API, or, more probably, most developers will not think of this at all, and their program won’t display messages on OS X, and Mac users will miss important information.
  • Similarly, there’s no way to determine whether popup menus or “default actions” are supported. The API guarantees that at least one is supported (I believe this is for OSX compatibility, because double-clicking an OSX status item does nothing). This means there’s no way for a Java program to even know what it’s doing (that is, whether the user can double-click the icon, or click to show a menu), and what the user is seeing.
    Imagine if an application needs to explain to the user how to open the application from the tray icon. It will have to say something like “Try double-clicking the icon. If that doesn’t work, try right-clicking it. If that doesn’t work, try to click it once. When you do these things, if you see a menu, choose the Open item. Otherwise it will open automatically.”
    I can’t imagine why Sun doesn’t want Java programs to be able to be aware of what their program actually does. Again, I expect a lot of hacky system property checks to determine these things.
  • displayMessage takes a TrayIcon.MessageType to determine what type of message it is: ERROR, INFO, NONE, or WARNING. MessageType is an enum. Using an enum prevents extension of the API in many ways because an implementation could not return an instance of a MessageType subclass, because you can’t subclass enum types. If Apple or BeOS wanted to add their own system-specific message type, they could not do so. Even if they added their own enumeration values to MessageType, there would be no way for Java code to access them without using reflection.
    Longhorn is coming out in a year or two and it may be that it has new types of tray icon messages, like, for example, a NETWORK_ERROR message type. A future OS X version could add status item alert messages, with more than just the four types specified in MessageType. With this API it will be impossible to use these from Java code, because this API uses an enumeration instead of a non-final class.

I may post about the rest of this API’s problems later.

If you agree that this API should be improved, you should post a comment here. If enough people post, it might convince Sun that there’s a problem, like it did with the applet browser lockup problem I posted about earlier this month.