[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ next ]
The following section describes how you can use Java in web browsers in order to be able to run applets published in web servers.
That is a tricky question. My answer would be: "No, but it doesn't hurt trying" (and don't forget to forward us your findings so we can update this document)
Yes, in Konqueror 3.1.1, you Settings->Configure Konqueror. The opened Control Module has a Java&JavaScript section where you can enter the location of your JVM. The configuration should look like this:
Selected "Enable Java globally"
Selected "Show Java console"
"Path to Java executable" has /usr/bin/java
As it says /usr/bin/java it relies on the
update-alternatives mechanism to point to a JVM that can serve as
a plugin. If you have Sun's J2RE installed, "Path to Java" might
also say something like /usr/local/lib/j2sdk1.4.2/jre/bin/java
Yes. Make a symbolic link in the /path/to/netscape/plugins
directory to the Java Plugin as can be found in Sun's J2RE:
/usr/local/netscape/plugins $ ls -la
total 960
drwxr-sr-x 2 root staff 4096 Apr 30 09:46 .
drwxr-sr-x 9 root staff 4096 Apr 8 20:26 ..
-rw-r--r-- 1 root staff 2363 Feb 8 07:47 ShockwaveFlash.class
-rw-r--r-- 1 root staff 946108 Feb 8 07:47 libflashplayer.so
lrwxrwxrwx 1 root staff 64 Apr 30 09:46 libjavaplugin_oji.so -> /usr/local/lib/j2sdk1.4.2/jre/plugin/i386/ns610-gcc32/libjavaplugin_oji.so
-rwxr-xr-x 1 root staff 19396 Feb 8 07:47 libnullplugin.so
If you have Blackdown's J2RE installed the link has to be made to
/usr/lib/j2se/1.4/jre/plugin/i386/mozilla/javaplugin_oji.so.
Other possible locations include
/usr/java/j2re1.4.2_04/plugin/i386/ns610-gcc32/libjavaplugin_oji.so,
you will need to locate this plugin depending on your installation.
Yes, the mechanism is identical to that of Netscape. However, the plugin
directory in this case is /usr/lib/mozilla/plugins. There is
additional information on how to install Java in Mozilla at the Java FAQ at
Mozilla
There might be some issues depending on your version. Mozilla 1.4 and later
(as well as Mozilla Firebox) is compiled with gcc 3.x and needs a compatible
version of the plugin, as provided by JRE 1.4.2 or later. If you find issues
you will need to debug yourself. A common problem is that the library might
not be binary compatible if it was compiled with a different gcc
version. Some gory details on how to debug this are described below
(contributed by Tim Freeman and included in the #debian faq
wiki)
The first problem is that in version 1.6-5 of the mozilla-browser
package, at least, /usr/bin/mozilla is a shell script that
redirects errors to /dev/null. This is described in bug
178271
To deal with this, make a copy of /usr/bin/mozilla and edit out
the redirects of file descriptor 2 to /dev/null and run the copy. You may see
something like this on Mozilla's standard error when it starts:
LoadPlugin: failed to initialize shared library /usr/lib/j2se/1.3/jre/plugin/i386/mozilla/javaplugin_oji.so [/usr/lib/j2se/1.3/jre/plugin/i386/mozilla/javaplugin_oji.so: undefined symbol: __vt_17nsGetServiceByCID]
This symptom indicates that your Java was compiled with an old version of GCC,
but your Mozilla was compiled with a newer version (post gcc 3.0.3), and the
two are binary incompatible. This is the case for version 1.3.1.02b-2 of the
j2re1.3 package from ftp://ftp.tux.org, at least.
If you're confronted with this symptom, the fix is to get a Java runtime that
was compiled with a more recent gcc. There are several available; one is
ftp://ftp.tux.org/pub/java/JDK-1.4.2/i386/01/j2re-1.4.2-01-linux-i586.bin.
Install that and change the libjavaplugin_oji.so link to point into the newly
installed Java runtime.
If you wish to confirm the diagnosis before attempting the above treatment, you can do it as follows. Confirm that your Java was compiled with the old gcc by giving the command:
c++filt -s gnu __vt_17nsGetServiceByCID
and getting the result:
nsGetServiceByCID virtual table
To confirm that your mozilla was compiled with the new gcc, you can find its version of the symbol by giving the command:
objdump -R /usr/lib/libxpcom.so | grep nsGetServiceByCID
and you'll see a line like:
000ec114 R_386_GLOB_DAT _ZTV17nsGetServiceByCID
Then you demangle that with the command:
c++filt -s gnu-v3 _ZTV17nsGetServiceByCID
and get this eminently reasonable output:
vtable for nsGetServiceByCID
The important thing is that the two calls to c++filt both succeeded but they were told to use different demangling rules, "gnu" for the first and "gnu-v3" for the second. If this all checks out, then you should fetch a newer Java runtime as described above.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ next ]
Debian GNU/Linux Java FAQ.
[email protected]