joustlog

I used JWS for a popular application called RPI Scheduler. It allows Rensselaer Polytechnic Institute students to plan their schedule for the next semester, based on the school’s course data. Thousands of students use it every semester.

I regret using Java Web Start for this project. It is not extensible, reliable, or user-friendly enough to support even my small application used by mostly computer nerds.

Java Web Start doesn’t work for a large number of users

Every semester I get about 10 posts to the program’s message board by people who can’t run the scheduler. I usually go through the process of looking through error logs and clearing caches and usually it doesn’t work, and these people simply cannot run the scheduler. These people all have the latest version of Java installed.

I imagine that most people who can’t get it working don’t post to the message board. Even if 1 in 4 post to the message board, that’s 40 out of a few thousand students, around 1-2%, who can’t run the scheduler at all.

Users don’t like the experience

Long ago, the scheduler used to be an applet. I get feedback from people saying they liked it better as an applet. I guess it’s for the same reasons that people like webmail: there’s zero setup, zero configuration, very short wait before it launches.

Java/JWS detection in the browser is necessary, and unreliable

To provide a good user experience you need to detect JWS and Java in the browser, so you can ask the user to download Java if they need to. There’s not an easy way to detect reliably from the browser. I use a hacky VBScript+Javascript combination from a Sun tutorial, which worked with some modifications. It only works well on Windows with IE. I had to make a page saying “If you think you have Java installed, click here” and so on, which a large percentage of users see (including all Linux and Mac users).

Users don’t know what JNLP files are

Users were confused about JNLP files. Users know what .exe files are, but not little 0.5kb JNLP files. Even if JWS is installed, Firefox users see this silly dialog asking whether to open or to save. The JNLP file on the user’s desktop does not have your application’s icon, it has a generic java icon (if Java is installed).

You cannot make the user experience much better

JWS does not allow your application installation and startup to look and feel smooth. On OSX, you might see several dock icons appear and disappear during startup. Some of them are Java icons, some are yours. There’s no way around this. Also, users are forced to see the ugly JWS download/install screen. You can minimize the visibility of this screen by using an “installer”-type JNLP file which only downloads a small installer jar.

If you want to put your application in the Start Menu or desktop, your users will see a disgusting, confusing dialog asking about “enabling desktop integration.” Most users click No, but I asked around, and many of those who clicked No said they would like to add the scheduler to the start menu, they just didn’t think it was possible. These people are Computer Science students.

The only reasonable solution is native launchers

I think the only reasonable solution for Java client deployment is to deploy native binaries (.exe, .app in .dmg, .rpm/.deb) which embed the JRE, or requires the JRE to be installed, or embeds the JRE installer in the application or in the app’s installer.

I prefer embedding the JRE because then you can have a single download page per platform and you know that it will work.

UPDATE: Kyle Cordes has posted some similar thoughts on Web Start.

Network Solutions charges an unreasonable $35/year for domain registration/renewal. If you call them to request a transfer to another registrar, they will lower it to a $15/year, if you stay with them. This is still an unreasonable price, but if you want to stick with NS, this is the way to go.

I’ve been thinking I wanted to learn about JAXB 2.0, because DOM (and SAX) code usually looks gross and is gross to write. To start learning, I visited this tutorial linked from the JAXB reference implementation home page and I think I’ve learned enough.

For a simple XML schema which defines 8 elements, the JAXB compiler generates 45 Java classes spread over 3 packages. To use the classes, I need to include 7 jar files in my application.

I’m going to stick to the DOM.

Some people think that because Eclipse is better than Visual Studio, it must be the best there is. I’ve made a table out of the Eclipse 3.2 M4 “New and Noteworthy” document which lists new features and describes which competitor already had that feature. Some features are indeed new, and are not implemented by any other product; however, most “new” features were already present in existing tools and frameworks (mainly in Swing and IntelliJ IDEA).

The table is here: Eclipse 3.2 M4 - Old and Already Implemented.

UPDATE: people are discussing this table at this JavaLobby thread.

IntelliJ IDEA’s plugin system allows you to add actions to menus, specifying the position in the menu relative to what menu item it should be above or below. However, the IDEA documentation does not provide a list of IDEA’s built-in menu and action ID’s.

I’ve learned a lot about XSLT today to produce a list of group and action ID’s built into IntelliJ IDEA. It is located here:

IDEA Built-In Action ID’s

Java has had the concept of beans and getters and setters for a long time. I thought we had all agreed that they work and clearly show intent. I felt annoyed when I saw the java.util.regex package appear in Java 1.4 with methods like matcher(CharSequence) and group(int), when they should have started respectively with create and get. I didn’t like so much the new Java 5 util.concurrent methods Executors.callable(Runnable), which should be prefixed with get or create.

I just now came across the new ProcessBuilder class in Java 5, with methods like redirectErrorStream(boolean) and environment() which should be a setter and a getter, respectively.

It’s harder and less pleasant for me to read my own code when using these classes. I hope Sun engineers will stop knowingly making Java code uglier in future releases.

I develop IntelliJ IDEA plugins and web applications. I must see “Can’t reload classes: add method not supported” 20 times per day. Then I shut down, wait 2 minutes for IDEA or Tomcat to start in debug mode, and continue debugging. I think I could get twice as much done in a day if I didn’t have to do this. I know there’s a bug in the Sun database but I can’t find it. The Sun issue report for this problem is 4910812.

Are you a slave to hot swap? Do you avoid renaming, extracting, or changing modifiers of methods so you can reload the classes? How do you get around it?

Javascript function closures probably don’t work the way you think they do.

UPDATE: I have modified my first example code to make the problem clearer.

My problem

I was writing some code today to dynamically insert a large number of HTML elements into the DOM, and give each of them a unique onclick function. My code looked vaguely like this:

[...]
var array = ...
for (int i = 0; i < length; i++) {
  var object = this.createNode()
  var picker = this
  var x = array[i]
  object.onclick = function() {
    picker.select(x)
  }
}

I needed to created a new function for each onclick because each one called select with a different parameter. However, I came across a problem that didn’t make any sense - when I clicked any one of the generated elements on the page, the last onclick function I had created was called. That is, if length was 31, then no matter which element I clicked, select was called with the 31st object in the array.

After hours of debugging and downloading Venkman and searching for information about Javascript closures, I finally found a discussion on the newsgroup comp.lang.javascript, in which Dom Leonard said:

Browser independant code *may not* rely on obtaining a different,
unjoined function object for *any* function declared inside another
function, whether this be because of function declaration or expression
within a loop, across calls to the containing function, or whether the
function be annonomous or named. ECMA 262 both *allows* them to be
different in all cases and *allows* them to share all external
properties (including prototype and user defined properties) in all
cases (because of join operations retaining differences in the scope
chain) and in some cases even *allows* them to be the same function
object without joining.

This was my problem - the browser appeared to be “joining” my function declarations into a single object, instead of creating a new function object for each iteration of the loop.

I’ll provide you with a solution in a minute, but first I have a fun demo for you. What do you think the following code will do?:

<html>
<head>
  <script type="text/javascript">
  function loadme() {
    var arr = ["a", "b", "c"];
    var fs = [];
    for (var i in arr) {
      var x = arr[i];
      var f = function() { alert(x) };
      f();
      fs.push(f);
    }
    for (var j in fs) {
      fs[j]();
    }
  }
  </script>
</head>
<body onload="loadme()"> 

</body>
</html>

If you think it will show alerts “a” then “b” then “c” then “a” “b” “c” again, you’re wrong. In Safari and Firefox, it produces “a”, “b”, “c”, “c”, “c”, “c”. Even though we create the function() in a loop, and x is stored as part of that function’s closure, the same function is used each time, and the closure information is replaced during each iteration.

A solution

I currently use a workaround for this behavior, as described in the comp.lang.javascript discussion. The following code works correctly, producing “a” “b” “c” twice:

<html>
<head>
  <script type="text/javascript">
  function createFunction(x) {
    return function() { alert(x); }
  }
  function loadme() {
    var arr = ["a", "b", "c"];
    var fs = [];
    for (var i in arr) {
      var x = arr[i];
//      var f = function() {
//        alert(x);
//      }
      var f = createFunction(x);
      f();
      fs.push(f);
    }
    for (var j in fs) {
      fs[j]();
    }
  }
  </script>
</head>
<body onload="loadme()"> 

</body>
</html>

However, even this code is not guaranteed to work correctly according to the ECMA spec. I don’t know what is the correct way to do this, according to the spec. If you think you’ve figured it out, please post a comment below.

Tal Liron is working on an AOL Instant Messenger server using joscar. It’s a very cool project, involving bridging many IM protocols. I’m excited because this will be the first real AIM server implementation using joscar. I’ll post a link here when he has a website and more information ready.

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.