The following bug was moved from NS-internal bug database as it seems to be related to more general JRE installer issue. The main idea is that the user should not have to re-install JRE1.3 over and over again to get the Java working as long the version of JRE currently installed on the user's hard disk works for Mozilla/NS builds. -------------- ** Observed with 10/27/2000 MN6 build ** Currently if you have a prior JRE installation and if you choose not to install JRE1.3 fresh under the Custom installation, the installer will still copy 4 NP Java 130xxx.DLL files into the Plugins directory. But the installer will not copy NPOJI600.dll whose presence is critical for Java plugins to work. I think we should copy or instal NPOJI600.dll even when the JRE install option is not chosen -- as long as the user has the correct JRE version for NS6. ------- Additional Comments From Sean Su 2000-10-27 13:06 ------- I am aware of this problem. I've already asked George Drapeau and Stanley Ho (both from Sun - George.Drapeau@eng.Sun.COM, stanleyh@single.eng.Sun.COM) as to the correct course of action for this issue. They have not responded to me yet. ------- Additional Comments From Sean Su 2000-10-27 13:07 ------- can someone move this bug to bugsplat, so that the Sun engineers can view this bug? Or is this not a good idea? ------- Additional Comments From Katsuhiko Momoi 2000-10-27 15:24 ------- Sean, I'll move it. I had thought that this was NS6 installer issue. Adn that's why I filed it here.

Copying module owner.

Sean, how soon could you work up a patch to the installer? Do you even know enough to do so? Monday's 11am (11:30?) PDT meeting may be our last chance to get bugs in.

Hi Sean: I don't understand the bug very well, but if I'm understanding correctly, it appears that the Netscape 6 Installer always copies some Java Plug-In DLL's into the NS6 plugins directory, even if you don't install Java. The bug appears to be that these are the old DLL's that we used in PR 1 and PR 2, right? If what I said was the case, then it appears that there are two problems, as I see it: 1) The NS 6 Installer shouldn't be copying DLL's anymore; Java Software fixed their JRE installer so that it looks for NS6/Mozilla and copies the correct DLL's into Moz's plugins directory. 2) The DLL's that NS6 Installer is copying are old, and should be replaced by the new, correct DLL's. I'm of the opinion that the installer just shouldn't copy those DLL's at all if the customer chooses not to install Java. It's a consistency thing that I believe will prevent this bug from occuring: if the customer chooses the Custom install option and chooses not to install Java, then two things should happen: 1) The JRE installer will not be called 2) The NS6 installer will not copy any Java Plug-In DLL's It seems wrong to me to do one of the above items but not the other, if the customer has chosen not to install Java. Later on, if the customer wants Java, s/he will either get it from java.sun.com (JRE 1.3.0_01, created specifically for Netscape 6/Mozilla M18), or will get it by going to a page with an applet, then clicking on the puzzle piece to auto-download the correct JRE from Netcenter. When this new JRE is being installed, that JRE installer will look for the browser and will correctly copy the DLL's. I believe this may leave one case where the customer may not be happy: if the customer chose not to install Java because s/he already has the correct version and doesn't want to duplicate the download process. My response to that: right now, there is no shipping version of the JRE that supports NS6 final release, since the correct JRE is not yet shipping. So many customers will have to get Java again later. For the remaining portion of people who get the JRE 1.3.0_01 or later in, say, December or after, *then* after that get NS6 (say, in February) but choose not to download Java, they will be stuck with no Java support because nobody installed the correct DLL's for them. I'd suggest either a dialog in the installer saying "Hey, if you're turning down Java because you already have it, you'd better go to java.sun.com to get the latest release, and it had better be 1.3.0_01 or later." Failing that, release note that puppy.

In part this bug is motivated by Netscape employees--especially those working remotely--who do not want to download JRE everyday. The Java installer might have copied the correct plugins into the N6 directory the first time, but for subsequent installations the N6 installer will have to do that. I guess when put in that perspective this is not crucial to the RTM branch so giving [rtm-], but we need to fix this for the trunk ASAP (a lynch mob is forming).

I disgree with George's assessment of this problem. As Dan said, for Netscape-internal users who install a build or two each day, downloading and installing extra 7.5MB every time is not desirable. Thus I at least regard the current copying behavior to be helpful. What I'm suggesting is that we should also install the OJI.DLL to complete the job properly. Now if I have the correct/mtaching JRE version installed on my machine, I don't want to re-install JRE. The key word here is "correct" JRE version. I think any Mozilla/NS build should have the Java version info, e.g. "Java >= 1.3.0_01" indicating the version needs to be later than 1.3.0_01. If the pre-installed JRE is equal or later, then the installer should copy the files. Otherwise, no. I think this notion of paying attention to the existing JRE environment matches the user's expectation and is kind to the user.

Okay, I see the rationale behind this bug. Seems reasonable to me that Netscape internal employees wouldn't necessarily want to re-install the JRE if they're re-installing the browser itself once or twice a day (!). I still think it's risky --- you'll have to be extra careful to make sure that you always have the correct DLL's in the installer --- but as long as this happens only for internal folks, hey, what do I care? The two places of risk, as I see it: 1) When Java Software gives Netscape release engineering a new JRE (you'll have to update the installer to use the DLL's in the new JRE) 2) When Netcenter gets a new JRE from Java Software. Ideally, when Java Software hands over a new JRE, it would go to both Netscape RE and Netcenter exactly at the same time, but I could believe that this isn't always the case. Now that I've said that, I guess this case isn't so crucial; I mean, if Netcenter and Netscape RE have different versions of the JRE, then that's a problem in itself, bigger than this bug.

Currently the following files are copied to my plugins directory using the mozilla-win32-installer: NPJava130_01.dll NPJava130_01a.dll NPJava130_01b.dll NPJava130_01c.dll Why would it be difficult to just add: NPOJI600.dll to the list of files copied? I have JRE 1.3.0_01 installed and I always use the Mozilla win32 installer, but I always have to copy the NPOJI600.DLL file my self.

This bug is pretty annoying for everyone who uses the installer builds. It should be most os all made CONFIRMED and ASSIGNED. I would suggest targeting it to mozilla0.8 as this is clearly a small input /big gain situation. As Henrik Gemal noticed: if the installer moves 4 JSE files to the Plugins subfolder, why not the fifth?

I agree with Jacek. It should copy the npoji dll as well.

Nominating for Mozilla 0.9. Java installation problems is the widest problem with Mozilla 0.7 as far as I can tell from comments/bugs, and I bet quite a few of them are related to this one.

Moz 0.8 tasks

fix coming up soon.

Patch will be attached to bug 66480 to eliminate duplicating patch attachments.

fixed.

fixed and verified...