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.

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.

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.

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.

People have been posting a lot about how cool they think GMail is, and how amazing Google Suggest is, and how XmlHttpRequest is going to change our lives, and I can’t take it anymore, I have to say something.

UPDATE: I’ve posted a follow-up to this article which explains more about why I think the web is not a cool platform for complex applications.

Part 1: GMail is a step backwards

People like GMail’s interface for some of these reasons:

1. It organizes e-mail into “conversations” so you can see how a series of e-mails progressed, and logically organize your e-mails
2. You can “Archive” e-mails instead of deleting them, so you can look through them later
3. You can search through your old e-mails
4. You can apply colored labels to messages automatically based on rules
5. It filters spam mail

My response to each of these features, respectively:

1. Netscape Mail / Mozilla Mail / Thunderbird has done this for years
2. Netscape Mail / Mozilla Mail / Thunderbird has done this for years
3. Netscape Mail / Mozilla Mail / Thunderbird has done this for years
4. Netscape Mail / Mozilla Mail / Thunderbird has done this for years
5. Netscape Mail / Mozilla Mail / Thunderbird has done this for years

(more…)