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 system or other interactive elements and any combination on those) inside of Ilias learning units.

We decided for Java because we wanted an open solution (and HTML5 was not really available at that time and Flash was and is not really an option).

Now, a few years later, I really got the feeling that Java is not really usable for the web. Mostly because of a lot of problems I haven't really been able to fix for all cases.

So, my question: Is Java just not the right thing for the web or am I doing something wrong? Can you point out how I could solve these problems?

Problems I have encountered in the time:

• 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?

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

• 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.

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

• 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.

• Sometimes, the Java applet doesn't load in browser X but in browser Y. After clicking a few times on reload or restarting the browser/system, that behavior may switch. For example, it seems that chances are higher that the applet load in Firefox (also not always, but mostly, at least after clicking one or two times on reload) and less likely on Chrome (but if I am lucky it also works sometimes). Depending on the system, it may be different browsers which work best. Though there is never a browser which works perfect. This behavior is on all the systems we have tested (different Linux distributions, both 32bit and 64bit, Windows XP/Vista/7, Mac OS X).

• 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.

• 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.

Some examples where we have these problems:

• http://www.matha.rwth-aachen.de/~ilias/jars/Integration/Integration_Geogebra.html
• http://www.matha.rwth-aachen.de/~ilias/jars/Abbildungen/Abbildungen.html
• http://www.matha.rwth-aachen.de/~ilias/jars/Trigonometrie/Trigonometrie_Geonext.html
• http://www.matha.rwth-aachen.de/~ilias/jars/AnalytischeGeometrieundLA/AnalytischeGeometrieundLA.html
• http://www.matha.rwth-aachen.de/~ilias/jars/ganze%20und%20natuerliche%20Zahlen/ganze%20und%20natuerliche%20Zahlen.html

If you look at these examples, what would be a good alternative solution to Java? I thought about HTML + JavaScript with recent browsers (it is not really a problem if we tell our users that they should use WebKit based browsers or so), although I think that some of these examples might be very hard to implement (or at least harder than in Java).

Mineraloid

Answer 1

Java applets were modern at the beginning of this century. There are only a few sites using Java applets today and this may be one of the reasons why the browser support is not optimal.

From what I've seen before my browser got stuck, your applets seem to be just drawing various charts.

I would suggest trying one of the modern JavaScript libraries which focus on drawing charts: http://javascript.open-libraries.com/utilities/chart/20-best-javascript-charting-and-plotting-libraries/

Alternatively, if you need more options than the libraries offer and you do not care much about cross-browser compatibility, you may use the <canvas> HTML5 element and SVG - all browsers except for Internet Explorer have decent support of these.

If you do not require the charts being interactive, you can render them on the server using PHP, Ruby, Python, Java, or whatever and send them as plain images to the browser.

If you need to express mathematical expressions, consider MathML or plain images possibly rendered on the fly by a server script.

Granulate

Yea, exactly this is what I am planning. :) Although I feel more comfortable in coding Java right now and I have also developed a framework now with all the functionality (2D/3D plotting, various math calculations, primitive Latex-like support, test/answer/help/suggestion system, ...). I am afraid that developing a similar thing in HTML5 would require more time than to do it in Java. It's really a shame that they have never improved the browser support (because I think that in theory, it should be possible to make this fast, fluent and stable). – Mineraloid

2D plotting is wrapped in that libraries I've linked. I don't know any 3D plotting lib but you can use WebGL (en.wikipedia.org/wiki/WebGL) or O3D (code.google.com/intl/cs/apis/o3d/docs/techoverview.html). WebGL is just an OpenGL API for JS so if you used OpenGL in your Java framework, it should be fairly easy to port it. Some basic math is wrapped in Sylvester sylvester.jcoglan.com . I also suggest moving as much as possible to the server (like the TeX things). You can reuse your Java code then. JS + HTML5 is definitely harder to code but your users will thank you :) – Granulate

The link is broken - it redirects to www.afternic.com and the URL contains "forsale". – Mannes

Answer 2

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...

Jessabell

There's not that much difference between WebStart and PlugIn 2. You can reference a jnlp file inside an applet tag (since 6u10). – Detention

Sure, but I think it a single app (be it an applet or a webstart app) will be much better than a dozen of applets sitting on a page. – Jessabell

That are just overview pages, not really intended to be viewed by the user. The user mostly gets a single applet on a page (or at least not multiple applets based on the same JAR). Also only in the case of Geonext and Geogebra, they are sharing the same JAR, not in the other cases. The problems I described occur just always. So at least I hope there is no such problem as you described for the end user. – Mineraloid

Ok, I think converting your existing applets into a single application should provide a nice improvement without requiring you to rewrite everything from scratch. Applets are much faster than what they used to be but the startup still takes a few seconds. On the other and switching screens in a standalone app will be very fast. Also it will give you full control on the lifecycle of the application (create/repaint/destroy screens). – Jessabell

That may be a solution for us, the developers, but not for the end-users because it should be embedded into the page. – Mineraloid

Answer 3

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.

Fairlie

Having said that, 19 applets on one page is ridiculous. Those are sample pages to just show give an overview over all applets. But why is it so ridiculous? A page with 19 small JS snippets or JS demos is also not. Or I can also start 19 Python scripts or other GUI applications within a fractal of a second without a problem. – Mineraloid

@Albert: Java is an external program embedded within the web browser. Launching 19 java applications (not applets) would be fine. Launching 19 JS demos would be... well, that depends entirely on the browser. It would definitely lag IE, and Firefox may also lag considerably. Launching 19 applets (external apps) from the same UI thread, that then try to allocate resources from the same resource-limited (and sandboxed) VM... – Fairlie

@R: Why does it use the same sandbox then? Why does it lag the browser? Why is the sandbox/VM so expensive? And why does it need so much resources? Why does it work only sometimes (even if the applets have nothing to do with each other)? Those applets don't really do much and are in most cases quite small. Well, maybe I should also blame the browsers here for bad integration. But why has nobody come up with a solution for it yet? Take a look at NaCl SDK for comparison. – Mineraloid

@R: Well this seems to be incorrect AFAIK. All applets would be loaded into one and only external process. Even different pages within the same browser process would be routed towards one and only VM. You may end up having some concurrency issues in the static code of course, but not much more than that. – Shifra

Answer 4

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.

Righteous

Answer 5

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.

Lixivium

No, mobile access is not really important. But an open solution is important. We also have some SPARC systems and it must run there too. Also some of the other/older Linux installations we have have some problems displaying Flash (and mostly don't have Flash installed). Also, me and most other people really dislike proprietary solutions like Flash, so it is anyway not an option. Also I don't know if I would have any IDE/compiler under Linux for it (but I also don't care that much -- as long as it is not open source, it is not an option). – Mineraloid

@Mineraloid consider Java Web technologies, such as JSF. It's still partially writing HTML (XHTML to be specific), but all the rest is real Java. No need to have to deal with JavaScript/ECMAScript. – Escapee

I'm with you, Albert. I don't care for Flash either, but thought it worth mentioning for the sake of completeness. :) – Lixivium

Answer 6

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.

Katalin

Wow, that looks interesting. Thanks for the link, I will check that out! – Mineraloid

Answer 7

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.

Detention

Have you tried those examples? They don't really do that much, the code is quite simple and small. They don't really need that much CPU (and none when idling) and no network or I/O. Also DNS is not a problem. – Mineraloid

I've not looked at the source, no. I tried the first URL, after I declined to trust a certificate I got hundreds of error windows. A load of junk in the [debug] console (which I believe is not implemented efficiently - there should be no reason for it to be efficient). Not good. – Detention

That first link is not even our own code. It is GeoGebra, a widely used Java application to draw geometry objects. And how is some output on the debug console inefficient? That is not the case for non-Java applications. Also, the output should be so small that it really should not matter. – Mineraloid

@Mineraloid I have no idea what it is. It does seem to be downloading several megs of (presumably compressed) jars and doing something with them. I don't suppose JavaScript would be much use there. – Detention

@Tom: It downloads one single JAR for the whole page (the Geogebra JAR itself), that is 26kb. Then it downloads a small ggb-file for each applet which is about 5kb. All in all, we are far under 1MB. It shouldn't even be notable that it is doing something. It is a joke in 2010 that Java blocks the whole webbrowser if it downloads a few KB of data. And that it blocks the browser at all, even whatever it is doing. – Mineraloid

@Mineraloid My recollection is that there were megs of related stuff in my Java temporary internet files. The PlugIn blocks the browsers only for a short time. It didn't used to be as good, but I don't think it ever blocked whilst downloading jars. – Detention

What is "PL&F"? – Mannes

@PeterMortensen PL&F is Plugable Look & Feel - Swing's mechanism for deep skinning. – Detention