64-bit Or 32-bit Java Jre With Firefox

Does the 32-bit java plugin for Firefox require the 32-bit version of the jre or can it use the 64-bit vsn of the jre, or does it operate standalone and therefore the jre vsn is irrelevant?

Last week installing another app caused a problem with my 32-bit Firefox which led to me installing the 64-bit version, but finally discovering the root source of the problem, I re-installled 32-bit Firefox. It is running fine, except that now the java plugin does not work properly.

I've re-installed the plugin of course, which is 32-bit. The plugin is symlinked as it should be in /usr/lib/browser-plugins (and I tried this from a tarball installation under ~/ as well, using the plugin folder under ~./mozilla) from the source file in /usr/lib/jvm/java-1.5.0.../libjavaplugin_oji.so. In firefox under aboutlugins, the java plugin shows installed, too. However, java applets fail to load. Running firefox from the shell, I get this error:

Exec of "/usr/lib/jvm/java-1.5.0-sun-1.5.0_update12/jre/bin/java_vm" failed: No such file or directory
** (Gecko:20285): WARNING **: Serious fd usage error 40
** (Gecko:20285): WARNING **: Serious fd usage error 38
Could not read ack from child process
Plugin: Java VM process has died.
plugin: java process died due to signal 11
Could not start JavaVM![/b]

This suggests that the plugin actually executes the virtual machine from the jre, and that it is looking for the jre under the 32-bit /usr/lib/jvm/.... directory. However, on my 64-bit installation, the java jre is actually under the /usr/lib64/.... directory. I don't recall reinstalling the jre as 64-bit; I had thought this was the default. But I don't want to just jump in and install the 32-bit jre only to bork something elsewhere.

Can anyone shed some light on which jre vsn the plugin needs, and whether it even uses it at all? I didn't have any issues with java apps before all this began, so whatever vsn of the jre I had, it worked fine, including with the plugin.

Thx in advance.

If you're running 32-bit Firefox, how do you expect it to handle 64-bit plug-ins when the math is computed correctly, will there not be null exceptions? If there were some form of emulation then maybe but you could. The reverse has proven to work with nspluginwrapper.

Take for example, you have a 32-bit operating system, then you try installing a 64-bit application, the process will fail. It may install if the installer is just copying files to a folder but execution of the program will fail.

The bottom line is if you are running a 32-bit Firefox, you can only run 32-bit plugins with it.

If you're running 32-bit Firefox, how do you expect it to handle 64-bit plug-ins when the math is computed correctly, will there not be null exceptions? If there were some form of emulation then maybe but you could. The reverse has proven to work with nspluginwrapper.

Take for example, you have a 32-bit operating system, then you try installing a 64-bit application, the process will fail. It may install if the installer is just copying files to a folder but execution of the program will fail.

The bottom line is if you are running a 32-bit Firefox, you can only run 32-bit plugins with it.
[/b]

Perhaps I did not state the problem clearly enough. I don't expect to use 64-bit plugins with 32-bit firefox. I'm not trying to do so. And with the java plugin it is academic anyway because the only plugin available is 32-bit.

The question is about the jre virtual machine relative to the plugin. It is conceivable that the plugin handles the applets entirely by itself without using the jre at all. On the other hand, it is also conceivable that the plugin calls the jre vm for execution; this is what the error suggested. I simply need to know what if any dependency the plugin has on the jre vm (i.e., the error msg could itself be an error or be misleading; wouldn't be the first time). Furthermore, even if the jre vm is called, it is also conceivable that 32-bit code is talking to/handing off to 64-bit code.

The only explainable reason for segfault error is that fact you're trying to access unassigned memory. Now I can only conclude you have your architects mixed. Check your Architects.

Upon further examining of your question, I wonder...

The question is about the jre virtual machine relative to the plugin. It is conceivable that the plugin handles the applets entirely by itself without using the jre at all. On the other hand, it is also conceivable that the plugin calls the jre vm for execution; this is what the error suggested.
[/b]

I don't understand how it is conceivable the plugin handles the applets by itself. What are applets? In this context, it is a .class file invoked by an html srcipt. What is a .class file? it is again in this context a java byte code compiled from java source code. So yes, plugins must call libraries to execute that machine readable code. All the plugin does is say look in here to get the right info for further instructions. The plugin cannot by itself execute a .class file, it require the java virtual machine (jvm).

Upon further examining of your question, I wonder...
I don't understand how it is conceivable the plugin handles the applets by itself. What are applets? In this context, it is a .class file invoked by an html srcipt. What is a .class file? it is again in this context a java byte code compiled from java source code. So yes, plugins must call libraries to execute that machine readable code. All the plugin does is say look in here to get the right info for further instructions. The plugin cannot by itself execute a .class file, it require the java virtual machine (jvm).
[/b]

Thank you, that's the kind of info I was looking for. It has been a long, long (did I mention, long?) time since I cut real code. So I'm entirely unfamiliar with java, or for that matter even browser constructs.

That answers half the question, i.e., whether the plugin calls the jre vm for execution. Answer: Yes. But, must that vm also be 32-bit like the calling plugin, or can the vm be 64-bit? It occured to me (duh!) to look inside the SUSE 64-bit install iso. What I found is the plugin in the i586 folder but the jre in the x86_64 folder. The 32-bit 1.5 jre is not in the iso at all. So apparently the 64-bit jre is installed by default and apparently it can be called by the 32-bit plugin installed by default.

So that suggests that the plugin is looking for the vm in the wrong place. Also interestingly, while in the 32-bit jre .rpm there is a file called java_vm (as called in the error msg), there is not such a filename in the 64-bit; there is a file simply called "java" which I suspect is the vm. Talking to a java architect, he said that the vm name is "java" not "java_vm", but of course java_vm could be a symlink or something else could be going on. I checked the ENV variables and all point to the 64-bit java & jre. So it appears that firefox or the plugin is being pointed to a specific filename ("java_vm") under a specific tree (/usr/lib) rather than the environment variable. Will dig further later . . .

Hoping someone knows how/what file points Firefox on SUSE to where the JRE is located. I think this is a SUSE thing because of SUSE 64-bit being hybrid, i.e., also including 32-bit libraries.

The env variables point to /usr/lib64 for the JRE. There are also two java control files, java.conf under /etc/java for system-wide and java.conf under ~/.java for user-specific which is optional. There is a SUSE readme in /etc/java that indicates this is used system-wide and includes instructions. I also found a C header file under /usr/lib/java-utils which, if executed, looks for these two files to set up the variables. I don't know if that code is being executed. But since the readme states that /etc/java.conf is used, then it must be being overriden by something else, i.e., firefox or the plugin is getting a /usr/lib/... path setting from another file. (I wonder if this might be in the same file that points firefox to /usr/lib/browser-plugins, which I think is also not the default firefox setup.)

I also tried changing the java settings in Firefox user.prefs (about:config), no help. And of course, removing the ~/.mozilla profile folder and recreating it; also no change.

Where is SUSE hiding these path settings?

Honestly Mingus, I've never encountered this problem with 32bit firefox on 64bit 10.2. Encountered others, for me the pros and cons of running a 32bit vs 64bit where generally transparent. But when i did encounter a problem my knowledge just wasn't good enough.

But as mentioned I've not got an installation, and I'll wait now till 10.3 as it can't be too far away.

As far as I remember the 64bit java bits are tied into Konqueror don't ask me how or why I just accept it. I just got left with the feeling why and how in konqueror but not firefox.

I thought you also needed to install 32bit java(Though I can't really remember), also doesn't nswrapper help, have you tried this way?

Honestly Mingus, I've never encountered this problem with 32bit firefox on 64bit 10.2. Encountered others, for me the pros and cons of running a 32bit vs 64bit where generally transparent. But when i did encounter a problem my knowledge just wasn't good enough.

But as mentioned I've not got an installation, and I'll wait now till 10.3 as it can't be too far away.

As far as I remember the 64bit java bits are tied into Konqueror don't ask me how or why I just accept it. I just got left with the feeling why and how in konqueror but not firefox.

I thought you also needed to install 32bit java(Though I can't really remember), also doesn't nswrapper help, have you tried this way?
[/b]

My 32-bit Firefox also worked just fine on 64-bit SuSE. The plugin is 32-bit but the JRE is 64-bit. Konqueror is 64-bit, and it calls the JRE directly; doesn't use a plugin. The path is setup in the Konq settings for Java.

Nspluginwrapper does not work for the Java plugin, only plugins that conform to the Netscape standard. Bottom line, there is no way for Java to work in 64-bit Firefox, no matter how it's sliced.

As a fyi aside for anyone, in 10.3 graphical Java does not work - either Java apps or the 32-bit Firefox plugin - without Java 1.6. There is a workaround for Java 1.5, but it doesn't always work. 1.6 adds a bash script which performs the workaround and sets up JRE execution so that it does work. However, on Beta3 at least the 1.6 plugin installation, which requires removal of the default 1.5 plugin, if broken. I upgraded to RC1 and it wasn't fixed, but it might be in the new RC1 installation.

Hi,

I install the 64bit 10.3 and Java, both jre 1.5 from the installation and jre 1.6 from java.com, did not work with FireFox.

I tried the jre 1.6 32bit, than the jre 64bit for FireFox. Both failed.

Only Konqueror works with jre 1.5.

Any clue, anyone?