Usability of Java applets on the web

Question

For our eLearning project in our university, we are using Java applets to show some interactive stuff (like some interactive function plotting or some simple question/answer

Answer 1

1. "A Java applet take ages to load."

Not really. Whey you load your first applet, you also load the JVM which, unlike the JavaScript engine, is not loaded when you start your browser. The JVM startup time are not longer than the JavaScript startup time, but the last one are hidden in the browser startup time... There are a project called Jigsaw which will split the current JVM into modules and make this initial startup much faster, and are scheduled for Java 9.

2. "The browser (or at least the tab in Chrome) gets very slow esp while loading the applet but also afterwards."

While loading the JVM, it's natural that things slow down. However, if the browser is slow afterwards, you probably have some bug in your applet that use excessive CPU time. This isn't any different from JavaScript which also can make the browser very slow. You may need to profile your applet in order to figure out where your resources go. I do have problems with Chrome, but its support for applets are known to be crappy...

3. "The Java applet looks different on every system."

If you use Swing with a non-native look and feel it does not. Personally I prefer the modern Nimbus look and feel.

How to set Nimbus look and feel in main

4. "Sometimes the memory usage is incredibly high (but not always)."

Profile your code, you are probably doing excessive memory allocations. Read up on object pools and other methods to decrease memory fragmentation. This are usually the sign of a badly coded Applet, rather than a problem with the Applet technology.

5. "When loading a page with multiple applets, the chances become very high that the browser crashes and or multiple applets don't load correctly. Also the whole operating system gets very slow."

Personally I would not have multiple applets on a page. See if you can merge them. Some browsers have very bad support for this. But more importantly it's not very user-friendly even when the technology do not mess it up.

6. "Sometimes, the Java applet doesn't load in browser X but in browser Y"

This is a known problem with modern browsers that tend to not support plugins well. This are actually the same problem as number 5. This problem are much more rare when you only use a single applet on your page.

7. "Sometimes, the applet stays blank when I switched to another tab and return back. Sometimes it at least takes a very long time until it shows up again."

Same problem as 5 and 6. The plugin code (NPAPI) haven't been modernized to properly support plugins. The browser is not telling the plugin that it must redraw it contents properly. Alternatively it may have crashed. This problem are also more rare if you only use a single applet.

8. "It eats up all the CPU. Even after I have closed all tabs with the applets. I have to quit the browser to resolve this."

Applets do not close when you close the tabs. They close when the applet exits, which you need to do in your code. Your code has to listen to some event, clean up, and exit. I don't remember the code for this as I usually copy-paste it. Also it's possible that AWT/Swing freaks out if you don't shut it down when its window resource dies...

On some of this you are right, and on others you have problems because you are using outdated libraries (like AWT or Swing with default look and feel) or do not understand how to manage the applet life-cycle.

Answer 2

A Java applet take ages to load. Even if it is a very simple small applet, it sometimes takes about a minute to load. Why is that? Is it really that the Java framework is so much bigger than Qt or other frameworks? Or is the VM so big? Or is the VM so slow?

That depends entirely on the machine it's running on, the web browser, and the Java version. I loaded the first example page you linked to, and while it did take a moment to load, it was also loading 19 applets simultaneously on a dual-core machine.

Having said that, 19 applets on one page is ridiculous.

The browser (or at least the tab in Chrome) gets very slow esp while loading the applet but also afterwards.

When loading a page with multiple applets, the chances become very high that the browser craches and or multiple applets don't load correctly. Also the whole operating system gets very slow.

I haven't noticed problems with the way applets load other than when you're loading a lot of them at once.

Again, this isn't just dependent on Java, but also the browser that loads it.

It eats up all the CPU. Even after I have closed all tabs with the applets. I have to quit the browser to resolve this.

Applets are not always unloaded when you leave a page. The applet's stop() method is always run when you leave a page, but the destroy() method and the actual unloading of the applet may not.

In Firefox 3.6, it appears to wait for 1-2 minutes before unloading an applet.

The Java applet looks different on every system. The UI controls are totally different and also behave slightly different. Sometimes it's the native look (or kind of it), sometimes it's completely something own. Also the font is mostly different and often supports a different subset of Unicode characters. This is a real problem for us because we use Unicode a lot for math symbols and we got a lot of reports that some symbols don't work for some people. Also as the font has different size on each system, I got reports that the text is cut out for a few people (or shortened by "..." in a JLabel). I have gotten around this problem now by including a TTF in the JAR. That works mostly. Still sometimes I get these "..." reports even with the unique font.

Java has two base applet classes. The first is the old-style java.applet.Applet class. The other is the newer javax.swing.JApplet class.

The former uses AWT for rendering, which builds on the system's native widgets. The latter uses Swing for rendering and should default to the cross-platform Metal (Ocean) theme.

The Swing tutorial has a page on How to Make Applets.

Answer 3

If mobile access is important, the HTML + JavaScript option is really the only decent one you have, as it's the most widely-supported implementation technology across all of the Apple devices, Android devices, and many of the other mobile devices that support WebKit. (We implemented all of the interactivity on the Texas State homepage this way. http://www.txstate.edu/)

If you're OK with desktop-only delivery, Flash becomes pretty viable, Steve Jobs' protestations to the contrary aside. :) Some of our learning modules are built on that technology.

Answer 4

If you know Java and are comfortable in applet code, look at GWT (Google Web Toolkit). It allows you to write Java code and it translates it to JavaScript.

Answer 5

Try WebStart. Basically, it allows you to start a standalone Java application from a web link. All your resources are cached client-side, so subsequents starts are much faster.

From the link you've sent, there seems to be a problem with Geonext. It does not seem to work well when there are several instances on the same page.

Have you tried to run the Geonext screens in a standalone Java application? It could also be a issue with your input data.

As far as the look and feel is concerned, you can set it explicitly if you want it to be OS independent.

It's quite possible that Geonext uses some static variables. This could create race conditions when a page contains several instances opened. You might want to check the documentation...

Answer 6

Most of these problems would appear from the description to be problems with the way the code is written. Unfortunately in our industry, quality is rare.

If an applet takes a minute to load that could be a DNS problem, or some other I/O related issue. (Is it dependent upon network, file or CPU?)

On modern computers memory usage is surprisingly difficult to measure effectively. The overhead of the JRE on a modern computer with gigabytes of memory should be pretty small.

If you use Swing, then the PL&F can be set to be cross platform (Metal, Nimbus or a downloaded implementation).

Fonts can also be dynamically downloaded.