Ok, something *just* hit me, and I checked: sure enough, that link was under amd64, and this new box is running Xeons. Now, the other admin says they're as compatible as any i386 instruction set.
And locate tells me the only libnpjp2.so is under amd64....
So, I'm stumped.
I have previously found that the 32-bit version of the new java plugin does not work under 64-bit - it crashes just like you described. Maybe it broke at a particular revision, maybe it never worked. The old 32-bit plugin did generally work on 64-bit.
When nspluginwrapper is present, the firefox wrapper script will always use wrapped plugins *instead* of native plugins, which in the case of java will go horribly wrong. This is a bug IMHO - the firefox wrapper should always put the native plugins first and then the wrapped ones.
/usr/bin/firefox: ... ## Select the propper plugin dir ## Wrapped plug-ins are located in /lib/mozilla/plugins-wrapped ## if [ -x "/usr/bin/mozilla-plugin-config" ] then MOZ_PLUGIN_DIR="plugins-wrapped" else MOZ_PLUGIN_DIR="plugins" fi ... if [ "$MOZ_PLUGIN_PATH" ] then MOZ_PLUGIN_PATH=$MOZ_PLUGIN_PATH:$MOZ_LIB_DIR/mozilla/$MOZ_PLUGIN_DIR:$MOZ_DIST_BIN/$MOZ_PLUGIN_DIR else MOZ_PLUGIN_PATH=$MOZ_LIB_DIR/mozilla/$MOZ_PLUGIN_DIR:$MOZ_DIST_BIN/$MOZ_PLUGIN_DIR fi ...
But wait, here's more: the firefox wrapper calls /usr/bin/mozilla-plugin-config, if installed. This script, in turn, runs $LIBDIR/nspluginwrapper/plugin-config, which is *suid*. So, every user running firefox messes around in system dirs. Who came up with that bright idea?