One of Sun's big marketing campaigns for Java was "Write Once, Run Anywhere", since supposedly the magic of Java was going to save the programming world from itself, and with a little sprinkling of Java all would be well. Unfortunately reality has proved... different.
Take for example the Sun X2200 M2 server which comes with a useful feature that allows you to see the (graphical) console remotely, the ELOM. This is a JavaWS blob which allows starting a Java application from the web, using JNLP. (Unofficial FAQ; Official FAQ) As best I can tell this is intended to break out of the "sandbox" in which Java Applets run so that they can do other things, while still allowing "click on a link in a web browser" as a means of starting them. (Essentially you get a little FOO.jnlp file which contains some XML that javaws can read to figure out where to download the rest of the application, and run it.)
The manual for the X2200 proudly says:
Note - The Remote Console does not require any special applications to
be installed on client systems. Client systems require only a web
browser with Sun Java(tm) runtime environment version 5.0 or later
plugins correctly installed. Java is available for free download at
http://java.sun.com.
but unfortunately that's not really strictly true. Because when you look more closely into how this remote console works, you find that included in the JAR file that it downloads are some native shared objects that implement various parts of the remote console functionality, in three files (JSecurity.so, SetDev.so and VDecode.so) -- plus a natively compiled program (sclient). And to ensure "portability" of this Jave application, there are three different versions of these native bits for different platforms (one appears to be semi-modern Linux, one is Sparc, and I'm not sure what the other is, but it seems to be some 32-bit x86 ELF platform -- possibly Solaris on x86; presumably they send a different bundle for Microsoft Windows).
On MacOS X 10.6 (using either the 32-bit or 64-bit JVM) you get an error like:
[ INFO ] - File Exist : s_VDecode.so
[ ERROR ] - error load sharded library into runtime environment fail
java.lang.UnsatisfiedLinkError: /private/tmp/127.0.0.1/s_VDecode.so:
no suitable image found. Did find: /private/tmp/127.0.0.1/s_VDecode.so:
unknown file type, first eight bytes: 0x7F 0x45 0x4C 0x46 0x01 0x01 0x01 0x00
(and so on for the other files), and then it eventually reports "Connect to remote host fail". Even on Linux you need extra libraries installed over the base for it to work, as someone with a "too recent" Linux found. (I got slightly different symptoms on Mac OS X 10.5, but it didn't work there either, although I didn't dig as deeply. And other people have had problems on MacOS X, and found a list of platforms supposedly supported -- which doesn't include MacOS X, and definitely isn't "no special software".)
There are newer versions of the firmware, including the ELOM, available but from what I can tell Googling no one has been able to make the ELOM work on MacOS X. And I think I understand why now. (Interestingly the HP DL380 remote console in my server does work with MacOS X, despite also being Java.) For some bigger servers with the ELOM it is possible to upgrade them to ILOM but this is limited to the X4150 and X6250 models. (The ILOM apparently does work on MacOS X.)
The working solution here, like many of these situations, seems to be to run exactly the environment that it expects, in a virtual machine, and then ignore the problem. And since both an appropriate version of Linux (eg Ubuntu 8.04 LTS that I was using on my previous laptop) and an appropriate version of Java 1.5 are available at no cost, this is definitely the lowest cost option. (The only other viable solutions are "have portable source code and recompile as required" or "use an interpreted language", but both require that you can get all the dependencies too. I met with a client today who had been running a GUI application in a virtual machine for a while because the library versions it depended on were not available in recent Linux versions.) (The other theoritical solution in this situation is to make serial console work and then ssh into the ELOM instead of using the GUI interface -- but that requires getting the ELOM and Xen and the Dom0 to all agree on the serial parameters, and to share the serial port.)
Since this is pretty much my experience any time I try to run any non-trivial Java application, "Write Once, Run Everywhere" seems to me to be just so much marketing. (And yes, if it were "100% Pure Java" -- another Sun slogan, meaning basically things which don't cheat in ways that might break like this, then maybe it wouldn't have this problem. But when Sun, the originators of both slogans -- "Write Once, Run Everywhere" and "100% Pure Java" -- can't get it right, is it any surprise may others don't either.) Portability is something you develop into a program, not something that's just there because you happened to use a particular technology. Especially not when, it appears, you're using that particular technology as (a) a GUI library and (b) an application launcher. (No wonder the remote console application "needs full control" of the computer.)
For the record, on MacOS X there is a "Java Preferences" application in "/Applications/Utilities/Java Preferences.app" which can set various preferences for running Java including which JVM (32-bit or 64-bit) gets used by default, and whether or not to display the Java console. (Without the Java console errors like the one above are completely hidden, and all you get is the dialog box telling you it couldn't connect.) It appears that "javaws -viewer" also starts this preferences application. (Other JavaWS MacOS X fixes) (MacOS X appears to be using DTrace instead of any other tracing framework, with the disadvantage that it has to run as root. Sigh.)
Also for the record, the ELOM needs ports: 80, 443, 8890, 9000-9003 forwarded to work. 80/443 are used for application download. 8890 is the remote console, and I think 9000-9003 are used for remote devices. (The ILOM apparently uses a different -- also undocumented -- set of ports.)
And now for something different:
Dear Sun,
If someone visits your website looking for information about one
of your products they do not want a "obscure a quarter of the page"
advert floating over the content that they're trying to read. And
the "We hare recommendations for you. If you're not interested,
click close" on each one reminds me of the common spammers refraint
"just click delete". Once might have been annoying, but tolerable,
marketing idiocacy. A few dozen times (literally) while looking
for a solution to the above problem is enough to drive one away
from your website permanently. I hope this isn't a sign of things
to come now that you've sold out to Oracle.
Yours,
A frustrated customer