Ruarí's thoughts

Does this seem a little harsh. Ok, let me explain.

Going back to my own investigation, my next step was to try IcedTea on my Arch 64bit install to see if I could replicate the plugin crash that enzolatina had seen. So I removed Sun/Oracle Java plugin and installed IcedTea, fired up Opera and loaded the Java test page. To my surprise it loaded and displayed correctly! I did see a little output in the terminal but nothing to cause major concern.

What put me on the right course to getting my head around this, was a comment provided by my friend Remco (Lanting). Since the IcedTea plugin was not detected on my Ubuntu install he suggested something I have often told users who find themselves with none working plugins, run 'ldd' against it. And guess what, its dependencies were not satisfied. You might wonder how Firefox is then able to run the IcedTea plugin but it immediately stuck me that this was very similar to one of the Flash problems that users often bump into. The required libs are found within Firefox's own libs directory rather than the system libs directory. Indeed it would seem that the IcedTea plugin needs Firefox/xulrunner libs to actually run. It is effectively dependant on Mozilla components being installed even though the packaging dependencies on Ubuntu don't mention this.

Don't believe me? Well if you are an Ubuntu 10.04 user install IcedTea and after confirming that it doesn't work with Opera and try the following:

sudo ln -s /usr/lib/firefox-3.6.3/libxpcom.so /usr/lib/libxpcom.so
sudo ln -s /usr/lib/firefox-3.6.3/libmozjs.so /usr/lib/libmozjs.so
sudo ln -s /usr/lib/firefox-3.6.3/libxul.so /usr/lib/libxul.so
sudo ln -s /usr/lib/libsqlite3.so.0 /usr/lib/libsqlite3.so

(note: In the last symlink, the eagle eyed might note that I am not linking to a lib within the Firefox directory but rather one on the system. I could link to the Firefox version of libsqlite3.so [it does bundle it] but I don't need to since the libsqlite package is installed. However IcedTea expects the file name to be named exactly libsqlite3.so or it will fail. Another IcedTea problem or a packaging issue for libsqlite? You decide, either way you have to work around it.)

Now load the Java test page. Does it work for you? I suspect it will.

Right, now it starts to get interesting! Some of you might be thinking that if IcedTea needs Firefox to be installed and even when it is installed it won't work in Opera because the libs are in the wrong place, wouldn't this also break other browsers? Yes it would and a Google search will quickly lead you to disgruntled users of other browsers such this Chrome user (whose blog post handily tells you how to install Oracle/Sun Java via the Lucid partner repositories). And it is not just Opera and Chrome, you can find complaints from users of other *nix browsers as well. Indeed you soon stumble across this Ubuntu bug report from a Chrome/Midori user. So yes, on Ubuntu at least, IcedTea only works in Firefox. Not due to some failing on the part of Chrome, Midori or Opera devs but rather due to Ubuntu packaging issues with the IcedTea plugin itself.

Before I go on, what about enzolatina's plugin crash? No, I hadn't forgotten. Having now tested IcedTea a little further I find I can replicate the same problem as him. On some more complex Java pages the plugin wrapper does indeed crash when IcedTea is used. What I don't yet know (since I have not yet got any of our plugins devs involved, nor extensively cross tested with Firefox) is if these crashes are due to some limitation in our plugin implementation or a failing of on the part of OpenJDK itself. None the less I'll sum up my thoughts thus far.

It would seem that on some distros IceaTea will work (albeit not consistently), on others it may fail due to packaging problems, in all cases it appears to depend on Mozilla libs.

So what would we need to do to get Java working for your average (Ubuntu) user before Opera *nix reaches a final. Well, assuming no fixes upstream either from distros or OpenJDK (within the required timescale ) it might still be possible to get the IcedTea plugin working in a similar manor to how it functions in Firefox but it would require some fairly ugly hacks. For example we would need to check on startup if IcedTea was installed, if so that the libs are satisfied, if not check if Firefox is installed, if it is installed check where it is installed, (assuming yes) if it includes the libs to get IcedTea working and (assuming yes again) preload them! Such hacks could have negative effects by introducing other bugs and will still fail in some cases. Consider that a user might uninstall Firefox but leave the IcedTea plugin installed. In which case it still won't work as the libs won't be available but the average user would have no way of knowing this was not an Opera issue. An even bigger problem is that developing such a hack is not free. We'd have to take development resources away from other bugs. Indeed on the testing side I have already spent most of a day looking at this when I would have preferred sign off on a number of nice fixes that we have lined up for *nix users (including more font work). So this issue has already introduced some delay in our preparations for the final.

In summary, we haven't yet decided what we'll do about this issue but I hope you now better understand the statement I made in the third paragraph of this blog post. To restate, personally I'd suggest users who want Java support to use the Oracle/Sun solution (for now at least).