The installer used to copy the NP*.DLL files so that Java worked in Mozilla. But with the new JRE 1.4 beta 2 it no longer works...

I tested w/ Mozilla 0.9.4 and JRE 1.4 beta. Copying the dll file into the plugins directory still works.

Looks like we specifically look for "1.3": http://lxr.mozilla.org/seamonkey/source/xpinstall/wizard/windows/setup/ext ra.c#6490 It would also be nice if the Mozilla installer did the copy as well as the Netscape one.

sean: could this be change so that we dont look for specific version number?

It would depend on how jre sets registry vars for other apps to detect "general" plugins (as opposed to specific versions). Either that or maybe have the installer enumerate all the keys within HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Plug-in and find the largest sub key value and use that. Perhaps specific version(s) of the browser only support specific version(s) of JRE, which in this case we should look for only the version(s) we can use.

over to Curt.

Curt- will this be fixed as part of bug 100393?

Does the Windows version of the JRE 1.4 also need to run regxpcom to be correctly installed?

WRT #7 Yes.

WRT #7 & #8 I should also have mentioned that the windows installer for the 1.4 JRE from RC on will run regxpcom automagically. In other words, the person installing Java on windows shouldn't have to run regxpcom manually to get it to work.

This is not the same bug as 100393. That is specifically for JRE 1.3.1, which is what ns certs against. As I understand it, we should NOT be copying the dll's for 1.4 since it uses components and registers them, which is fundamentally different--although it does still seem to work with the dll's. As Steven notes, the JRE installer should be taking care of that registration step so I'm inclined to this this bug should be closed as invalid. Someone know differently? I'm cc'ing Joe Chou from Sun to verify that I speak the truth.

Installing the JRE 1.4 (by downloading the JDK 1.4 *RTM* from Sun's site) doesn't correctly work with current trunk Netscape Commercial builds. In fact, my 1.3 plugin is removed and I'm left with no Java working. Checking the check box in the control panel for Netscape 6 did not work. Manually running regxpcom on the JPI DLL in the installed location didn't seem to work either. How do I get JRE 1.4 to work with current Netscape commercial builds? Is the same experience true for current Mozilla trunk builds? Possibly the reason this bug was opened.

Peter: I tried to download Mozilla trunk and run regxpcom with JRe 1.4 and it does not work. However, it does work with Mozilla 0.9.7/0.9.4. This obviously means that it is caused by some change of Mozilla code. Nothing to do with JRE 1.4. Check Netscape 6 box in Control Panel won't work for Mozilla. I think you can try to put NPOJI610.dll in Mozilla component directory and remove component.reg from Mozilla dist bin dorectory. Maybe that will work.

hm...okay...reassigning to XPCOM for further investigation...

several of the core interfaces are not frozen and have been changing as we try to freeze them for 1.0. If the current JRE 1.4 component works against 0.9.7 and no longer works it was probably depending on one of these unfrozen interfaces.

Copying any part of the plugin into the "components" directory is NEVER the right thing to do. We didn't intend the plugin to work this way and we don't test the plugin with this configuration. I don't know how people got the idea this was a viable option.

XPCOM successfully finds the NSGetModule symbol and calls into it. The problem is somewhere in OJI. I am not sure what is happening since I do not have source code to this code. Here is the stack which results in a print of "runtime error": _NMSG_WRITE(int 0x000000ff) line 221 _FF_MSGBANNER() line 169 + 10 bytes _amsg_exit(int 0x00000019) line 324 _purecall() line 35 + 7 bytes NPOJI610! 014a13fa() nsNativeComponentLoader::SelfRegisterDll(nsDll * 0x00481a80, const char * 0x00480b60, int 0x00000000) line 488 + 63 bytes nsNativeComponentLoader::AutoRegisterComponent(nsNativeComponentLoader * const 0x00416df0, int 0x00000000, nsIFile * 0x00481af0, int * 0x0012febc) line 933 + 23 bytes nsComponentManagerImpl::AutoRegisterComponent(nsComponentManagerImpl * const 0x004150bc, int 0x00000000, nsIFile * 0x00481af0) line 3226 + 42 bytes nsComponentManagerImpl::AutoRegister(nsComponentManagerImpl * const 0x004150a8, nsIFile * 0x00481af0) line 3341 Register(nsIComponentRegistrar * 0x004150a8, const char * 0x00414c67) line 72 + 21 bytes ProcessArgs(nsIComponentRegistrar * 0x004150a8, int 0x00000002, char * * 0x00414c20) line 162 + 19 bytes main(int 0x00000002, char * * 0x00414c20) line 204 + 22 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 7 Xiaobin, if you would like to drop by I would be happy to debug this with you.

As far as i can see regxpcom crash is happen when jpi tries to call nsIComponentManager->registerComponentWithType(). I guess this particular crash is due to recent (Dec 18 2001) change of *frozen* interface nsIComponentManager (see bug 98553) and history of nsIComponentManager.idl. In general regxpcom & java plugin problem is "raising phoenix" one and usually takes a while to be solved (because the only solution by now is to update java plugin to new interfaces). Looks like it would be nice to think of some kind of alternative solution (might be non-permanent) that will eliminate this (glue level in pure C that will be used for plugin callbacks?). I know this is not quite consistent with XPCOM methodology but frozed interface changes as well as C++ mangling problems in different compilers (see bug 116444) are really too frequently reported and very annoying.

The problem reported in comment #16 is not specific for win platform. See also bug 116412. Shall we change platform to All or we want keep crash separately from the originally reported problem?

reassigning to Joe.

*** Bug 116412 has been marked as a duplicate of this bug. ***

Currently, Sun's Java plugin group is considering to straiten out the problems of using regxpcom. One possible solution will be to copy the Java plugin lib back to plugins directory. Util then, here is a work around: for Unix, make a symbolic link of the Java plugin lib to plugins directory; for Windows, just copy the plugin lib (NPOJI140.dll for 1.4, etc.) to plugins directory.

ok... auto detect is the best solution. until then just follow http://gemal.dk/mozilla/java.html