Day 5: applet, or object?

Applets have many, many compatibility issues between different browsers on different platforms. The recommended answer to this is to require your end users to install Sun's "Java plugin", to ignore the applet tag, and to use an object tag instead.

I don't like forcing my users to install any software they don't want to. The whole point of applets is to avoid exactly that issue. If they wanted to install stuff, they could install my own application!

But anyway, we could possibly do that. What would this mean for us? Our current applet tag is as follows:

<applet code="ThudChat.class" width="711" height="817" archive="ThudChat.jar" width=600 height=350>
<param name="host" value="217.155.157.36">
You need to install a Java interpreter to run this applet. Try here: 
<a href="http://java.sun.com/products/plugin/">http://java.sun.com/products/plugin/</a>
</applet>

That's a bit wordy, maybe. But to get Sun's Java plugin working on more than just IE/Netscape, we'd need something more like:

<SCRIPT LANGUAGE="JavaScript"><!--
    var _info = navigator.userAgent; 
    var _ns = false;
    var _ie = (_info.indexOf("MSIE") > 0 && _info.indexOf("Win") > 0
        && _info.indexOf("Windows 3.1") < 0);
//--></SCRIPT>
<COMMENT><SCRIPT LANGUAGE="JavaScript1.1"><!--
    var _ns = (navigator.appName.indexOf("Netscape") >= 0
        && ((_info.indexOf("Win") > 0 && _info.indexOf("Win16") < 0
        && java.lang.System.getProperty("os.version").indexOf("3.5") < 0)
        || _info.indexOf("Sun") > 0));
//--></SCRIPT></COMMENT>

<SCRIPT LANGUAGE="JavaScript"><!--
    if (_ie == true) document.writeln('
<OBJECT
    classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
    width="200" height="200" align="baseline"
codebase="http://java.sun.com/products/plugin/1.3/jinstall-1_3_0_05-win.cab#Version=1,4,0,mn">
    <NOEMBED><XMP>');
    else if (_ns == true) document.writeln('
<EMBED
    type="application/x-java-applet;jpi-version=1.4" width="200" height="200"
    align="baseline" code="ThudChat.class" codebase="html/"
    model="models/HyaluronicAcid.xyz"
    pluginspage="http://java.sun.com/j2se/1.4/download.html">
    <NOEMBED><XMP>');
//--></SCRIPT>
<applet code="ThudChat.class" width="711" height="817" archive="ThudChat.jar" width=600 height=350>
</XMP>
    <param name="host" value="217.155.157.36">
    <PARAM NAME="java_code" VALUE="ThudChat.class">
    <PARAM NAME="java_codebase" VALUE="html/">
    <PARAM NAME="java_type" VALUE="application/x-java-applet;jpi-version=1.4">
    <PARAM NAME="scriptable" VALUE="true">
You need to install a Java interpreter to run this applet. Try here: 
<a href="http://java.sun.com/products/plugin/">http://java.sun.com/products/plugin/</a>
</APPLET></NOEMBED></EMBED>
</OBJECT>

Actually, that's just a best guess at what we'd need. That's what they have on <a href="http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/using_tags.html">java.sun.com</a>, but it's prefixed by:

That is to say, they don't know if even that ugly mess will work with recent browsers.

There are many, many suggestions to get around this compatibility problem. Here are the most popular:

1. Don't use Applets.
2. Only support one browser.
3. Only support one platform.
4. Get users to install all non-core components, eg Swing.
5. Use the same version of the JDK supported by the browsers (ie require them to use that version)
6. Require the users to install the Java Plugin (and make the changes described above to the HTML)
7. Code in Java 1.1 only, to be compatible with 4.06+ and Internet Explorer 4.01+. 4.06+ and Internet Explorer 4.01+.

It seems to me that the only reasonable, polite suggestion above is the last one. All others are making unreasonable demands on the user. Hence the hoops I am jumping through.

And then there's the whole "different security models" thing. Different versions, platforms, etc, have different implimentations of the java security model. Some stuff is legal in one, and needs the user to jump through hoops in another. You can sign the applet, but there's no universally recognised way of doing that. Again, there are many suggestions.

1. Have your users change the security model on their side.
2. Sign the applet as best you can, and have the users accept the signature.
3. Don't do anything that would need any trust from the user (accessing local files, connecting to machines other than the one you were downloaded from...)

Again, it seems that the only polite thing to do is the last one: don't cause security issues in the first place. This means that the download server must have the same IP as the game server, but that's a small price to pay.

Apparently, older versions of some browsers do not support multiple archives, and support uncompressed ZIP files only. I'll cross that bridge if it ever arises, in the meantime I'll use multiple compressed JAR files.

All of this makes me very very sad. Java used to be such a hopeful language. It was the language that was going to make the internet truly interactive, rather than just passive surfing... instead made pages unviewable. It was the language that would cut through the morass of system and platform dependencies... and instead it added browser dependancies to the list.

I still have the '96 (Java 1.0) version of O'Reilly's "Java in a Nutshell". Reading it now, the words are filled with pathos. "The network will become the computer," we were promised. they envisage document-centric systems, where people would email eachother documents with the embedded wordprocessor needed to view or read them. "Or a "game broker" that acts as a matchmaker between players, who then communicate directly with eachother to play the game, without the server's intervention. The fact that these applications don't exist yet just means that we haven't figured out how to use the full power of Java." No, it means that that's the wrong architecture for an online game If you're keeping score, you need a referee. And anyway, Java's security system means they can't connect directly to eachother anyway.

But already the death knell had sounded, and incompatibility was looming. They just didn't know it yet. "As this book goes to press, even Microsoft has announced its intention to license Java."

In "The Java Language: A White Paper", Sun described Java thusly:

How does it stand up to these claims today?

1. "simple" - HAHAHAHAHAHAHA! That's so sad. No, it has grown into a behemoth. Very little of it is simple.
2. "object oriented" - Yes, it's still OO. Fanatically so.
3. "distributed" - No. The best that can be said of it is that it is network-aware, and that because you can use it in applets, you can sometimes, with a lot of work, offload processing work to the client side. But there's nothing inherent in the design that would lead someone to call it "distributed".
4. "interpreted" - well, yes, it's still interpreted.
5. "robust" - yes, it remains difficult to crash the machine with Java. Though, writing a Java program that doesn't fall over remains an art.
6. "secure" - yes, it's secure, in that it's sandbox-crippled. I like this. I think more languages should do this. The fact that Java took the security/functionality tradeoff and made it work was one of the things that made us think it was going to be great.
7. "architecture neutral" - Y...yeah. Kindof. If you're willing to stick to 1.1 and no Swing. These are significant hoops, given that Sun doesn't support 1.1 anymore, at all.
8. "portable" - No. 'java goes even further, by ensuring there are no "implementation-dependant" aspects...'. This is no longer true, by a long chalk.
9. "high-performance" - for a long while, until the advent of JIT compilers, this made an oxymoron with "interpreted". It's better now, but anyone who's loaded Sun's Java for the first time and seen their machine grind to a halt knows that this isn't the whole story.
10. "multithreaded" - well, yeah, but stuff's not a proper language if it can't do threads.
11. "dynamic" - Yes, and this is cool. It can load new classes at runtime, even over a network.

I wait for its successor, or perhaps for Java itself to rise again from its own ashes. In the meantime, I mourn the passing of a great and lost opportunity.