58267 - NPOJI600.DLL is not installed in Plugins directory when Java install option is not chosen

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P3)

Description

[Katsuhiko Momoi]

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 - [e-mail], [e-mail]) 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.

Comment 1

[drapeau]

Copying module owner.

Comment 2

[Daniel Veditz [:dveditz]]

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.

Comment 3

[drapeau]

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.

Comment 4

[Daniel Veditz [:dveditz]]

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).

Comment 5

[Katsuhiko Momoi]

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.

Comment 6

[drapeau]

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.

Comment 7

[Henrik Gemal]

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.

Comment 8

[Jacek Piskozub]

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?

Comment 9

[edburns]

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

Comment 10

[Fabian Guisset]

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.

Comment 11

[Daniel Veditz [:dveditz]]

Moz 0.8 tasks

Comment 12

[Sean Su]

fix coming up soon.

Comment 13

[Sean Su]

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

Comment 14

[Sean Su]

fixed.

Comment 15

[Henrik Gemal]

fixed and verified...