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.

Thanks to the QTComponents project, you can listen to music in Ogg Vorbis format with iTunes. However, the plugin does not import track numbers, which means iTunes plays albums of Oggs out of order.

A small Python script was posted a year or two ago at Mathieu Fenniak’s weblog which tries to fix this, but it doesn’t support the track numbers in files which also specify a track count (like “5/12″ to mean track 5 of 12).

I’ve fixed the script to support these files. You can download the fixed version here.

A week or two ago I posted an article here asking if anyone else’s browser locked up when a Java applet loaded. I did this because a Sun engineer, Jitender, said he or she “could not reproduce the momentary freeze” when I filed a bug report about it.

After I replied to Jitender with the responses I got to that article, they accepted the bug into the database. It’s Bug 6267809: Java applet on page causes browser to hang until Java is loaded.

Thanks to everyone who posted replies to the original article.

The bug

I filed a bug report to Sun after I was very surprised to find it had not already been filed, years ago. I got a response from a Sun engineer named Jitender:

“I tried this but could not reproduce the momentary freeze you have mentioned. It seems it could be related to RAM also. Even more RAM requirements are mentioned in JDK 5.0 Installation notes available at http://java.sun.com/j2se/1.5.0/install-windows.html”

I have 512MB RAM, a 1.8Ghz P4-M, and a 5200RPM disk. Visiting a Java applet locks up for about 10 seconds the first time I visit. It happens to my friends, in IE and in Firefox, on Windows and Linux. I think it’s obviously not “not reproducible.”

Help get this fixed

So, tell me - when you visit a page with a Java applet, does your web browser completely lock up for a few seconds? If you’re not sure, visit this calculator applet and count how long your browser is unresponsive. If you notice any freeze, please leave a comment below with your system specs (memory, CPU, disk speed if possible) and how long it froze for.

Your results will be most useful if you make sure all Java programs on your computer are closed, so we get a “cold start” time. It would be even better if you restart your computer and don’t run any Java programs before visiting the above web site. However, any results will help!

I will forward your list of lock-up times and system configurations to Sun, so maybe they will believe me. I think fixing this problem would be a huge step towards Java being more accepted on the desktop.

UPDATE: The bug was filed as Bug 6267809 and was quickly marked “Closed, not a bug.” You should post your lockup times as comments to that bug, instead of here. I have posted all previous comments here as comments on the bug as well.

According to Graham Hamilton’s weblog entry, Java 5.0 Update 3 will not be distributed via java.com or the JVM auto-update feature, supposedly so as not to confuse users. This is despite Update 3 being informally labelled “the ‘.1′ release of the Tiger family” by Sun.

It looks like if you want your application to run on the latest Java 5.0, you have to ask your users to go through the tedious and confusing java.sun.com download page, with the invisible yellow button text and list of seemingly identical (but very different) download links.

If you want Sun to distribute the latest Java update in a way that makes it easy for users to upgrade, I suggest you post a comment on Graham’s weblog entry. I think with enough support they may change their policy.

I’m working on a project which uses JShortcut along with JDIC IconService, JDIC FileTypes, and Glazed Lists to allow you to quickly search through the programs in your Start Menu.

Here’s a screenshot:

There are lots of programs that do this, but they are all shareware, or for other operating systems, so I’m writing my own.

This is a brand new project but the basic search functionality is there, as you can see in the screenshot. Some icons don’t show up because of some JDIC bugs, which will hopefully be fixed soon.

I have a bunch of plans for this project, including:

• Create JDIC subproject out of JShortcut, or integrate it into JDIC FileTypes
• Add Linux and OSX support

It looks like I’m going to have to write my own library with JNI for setting global (desktop-wide) hotkeys, as well as to watch a folder for changes.

I can’t think of a name for this project; any suggestions would be great, just post a comment.

I will create a java.net page for this project as soon as I find a name I like.

Recently Joshua Marinacci announced that he was developing a new JDIC sub-project called “JDIC Misc.,” which provides some cross-platform functionality which does not fit in any of the other JDIC projects.

JDIC Misc. allows you to:

• alert the user that an important event has occurred in your application (like AIM or iChat does when you receive a message).
• show a custom menu on the taskbar/dock item(s) for your application
• manipulate the computer’s master sound volume
• set the desktop wallpaper

I looked at the Javadoc for these new API’s and saw lots of design, implementation, and code style problems. I will discuss them here.

Design problems

Read the rest of this entry »

I posted an article about three months ago called “Google Suggest and GMail are a step backwards,” (you can read it here) and many people read the article and thought that I meant something that I didn’t.

I’ve had time to think about the issue some more, and I’ve talked to people about it, and I think I can make my opinion clearer this time.

This entry is more technically oriented than my last entry, and you can probably read it more easily if you’re familiar with programming and software development.

Introduction

Web application development and desktop development have their benefits, but the latest trend of complex web applications like GMail and Google Suggest are abandoning years of desktop development progress for the simple reason of easy application deployment.
Read the rest of this entry »

From Ingrid Yao, leader of Mustang CAP program:

Here is Mustang release schedule:
Dev Freeze: 8/11/05
Beta Ship: 11/3/05
RC Ship: 3/30/06
GA Ship: 5/11/06

It looks like the 6.0 Beta will be out in November, and final release will be a year from this May.

It looks like I’m not the only one who thinks Google’s web apps are driving technology backwards. Charlie Hayes has posted his own thoughts on Google and rich web apps, called “Rich web apps, GMail, and Suggest get bashed like none other, for good reason”.

Charlie makes some points that I hadn’t thought of, about what happens to your webmail when your Internet connection is down, and that we all have 1GB free on our home computers, and he explains a bunch of other reasons why native applications are often easier to use.