53906 - New Installer for Windows Java 2 support

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P1)

Description

[drapeau]

Java 2 bits are now being delivered in a different, simpler way from previous 
deliverables.  There is now a single .EXE file being delivered, as opposed to 
two files.  (old delivery: JRE + OJI patches to the JRE; new delivery: JRE 
1.3.0_01 now includes Netscape6/Mozilla M18 OJI support).

Here's what I recommend for installing:

* Take the .EXE file (an InstallShield installer), turn it into a .xpi to your 
liking
* This Win32 installer will install the JRE, then will look in the Windows 
registry for Netscape 6.  If found, the JRE installer will itself install the 
proper DLL's into Netscape 6 plugins directory.  No extra action is necessary on 
N6 installer's part.  (old way: N6 installer let the JRE installer run, then N6 
installer took the patched DLL's and N6 installer copied them into the N6 
plugins directory.  No more of that.)

This means that N6 registry keys must be registered in Windows registry before 
the JRE installer is run.

Questions?  Please ask [e-mail].

I hope this is clear; please let me know if not.  Java will not work in PR3 and 
beyond without this fix.

Comment 1

[drapeau]

Nominating for NSBeta3 and RTM, assigning P1 priority: Java will not work 
without this fix.

Comment 2

[Daniel Veditz [:dveditz]]

fyi, nominations are keywords, the approvals go in the status whiteboard.

I'm empowered to give nsbeta3+ (which I'm doing), but checkins now require a 
nsbeta3++ from the PDT.

Comment 3

[drapeau]

Oops, my bad.  Sorry for putting the nomination in the wrong field.  I should 
know better.  Thank you for the correction.

Comment 4

[drapeau]

Instructions and information from Stanley Ho at Sun, from the Java Plugin group:

	In this PR3 release, the JRE installer will actually install all the
plug-in DLLs into Netscape 6/Mozilla by looking up the Netscape 6
registry keys. There are five DLLs that the installer will copy into the
Netscape 6's plugins directory:

	NPJava130_01.dll
	NPJava130_01a.dll
	NPJava130_01b.dll
	NPJava130_01c.dll
	NPJavaOJI600.dll

	In order to get the JRE installer to work, Netscape 6 MUST be installed
through an installer, so the proper Netscape 6 registry keys will be
entered into the Windows registry. It also means that by the time the
JRE installer is launched by Netscape, all the Netscape 6 registry keys
MUST already be installed into the registry; otherwise, the JRE
installer won't be able to locate Netscape 6 to install these plug-in
DLLs. If the installation is successful, you will find the above DLLs in
the Netscape 6's plugins directory.

	There is one catch!! If the users happen to have older version of the
plug-ins install with Netscape 6 PR3 for some reasons, they will have
NPJava11.dll/NPJava12.dll/NPJava32.dll in their plugins directories. All
these DLLs MUST be removed with PR3 because they will crash the browser.
This information should be in the Release Notes.

	Also, in PR1/PR2, Netscape 6 installer will try to locate the 1.3 JRE
and copy the NPJava*.dll over. We DON'T need to do it anymore. The
Netscape installer should no longer perform this logic.

	Finally, we need to make it clear to the users that Netscape 6 ONLY
works with JRE 1.3.0_01. This also should go into the Release Notes as well.

Comment 5

[Grace Bush]

adding relnote keyword for tracking

Comment 6

[Daniel Veditz [:dveditz]]

Getting late for a PR3 fix -- where are the bits and the patch to fix the
problem? Will minus tomorrow if the PDT doesn't beat me to it.

Comment 7

[drapeau]

Sorry about not updating this sooner.  I sent the bits to leaf over the weekend, 
with instructions posted to this bug.  I believe ssu and stanley have been in 
contact about this.

If there's anything I can do to help expedite, please let me know.

Comment 8

[Sean Su]

I still need info from Stanley on how the JRE installer determines where it 
installs itself (the main product, not the plugins files for Netscape 6).  I 
already know how it determines where to put the dlls for the Netscape 6\Plugins 
folder.

I need this info so I can make sure the user has enough disk space to install 
JRE prior to running the JRE installer in silent mode.

Comment 9

[Phil Peterson]

Why is it that our previous Java bits won't still work for PR3? Are we really
Java-less for PR3 if we don't take this big new drop? A big new drop like this
at the last second before PR3 is really not the way we'd like to work. If we're
really Java-less without this, then I guess we have to ++ it.

Comment 10

[drapeau]

phil: I don't know if the PR 2 Java binary you have will work with PR 3, but 
even if so, the reason I ask for inclusion of this latest drop is that the PR 2 
Java was not feature-complete.  We aimed to get the last major functionality in 
(JavaScript<--->Java security), but missed the PR 2 deadline.  All of that stuff 
is in both the current Mozilla code base and in the current Java Plug-In.
In addition to this, there are modifications in the latest Java Plug-In drop 
that help fix a number of lifecycle-related bugs (some changes in the browser 
codebase as well; this was a coordinated bug fix for Plug-In and Mozilla).

The PR 2 Java that you have might work, but it will be a lower-quality product.  
It makes the installer more complex to put together, and therefore more 
error-prone.  It also makes auto-download of Java more problematic (two XPI 
files on the plugin-finder page instead of one for PR 3).

That's my case.

Comment 11

[stanley.ho]

Let me clarify this: the PR2 Java binary Netscape has won't work with PR3/FCS 
release. 

Reasons: because the underlying XPCOM interfaces has changed between PR2 and 
PR3/FCS. It means that the Netscape binary is compiled against one set of 
headers while the Java binary is compiled against another set of headers. The 
compiler will generate different vtable layout for the XPCOM interfaces 
depending on the set of headers. When you try to mix the PR2 Java binary with 
the PR3/FCS Netscape 6, I can ensure you that it won't work. We are just lucky 
that the basic interfaces to load the OJI plug-in hasn't changed, so you are 
able to load it in PR3. However, once you start exercise the OJI plug-in more, 
it will step into using XPCOM interfaces that has been changed, and it will 
crash the browser right away. This is pretty bad consider we don't want any 
crash bugs in the browser. This is why we want the XPCOM interfaces to freeze 
as soon as possible. Otherwise, every time there is a XPCOM interface changes, 
there is a risk to break Java!!

The other reason is that as George said, the PR2 Java binary is not feature 
complete. It has couple security related issues that has been addressed in the 
latest Java binaries. Also, the PR2 Java binary is not fully tested, and it is 
not an offical release from Sun. There will be a legal problem if Netscape 
distributes ther PR2 binaries with the Netscape 6 FCS release.

In this latest binary, it is an offical JRE 1.3.0_01 beta release from Sun, and 
this is what we want Netscape to distribute in the PR3 release. When Netscape 6 
FCS code freeze, we will provide an offical JRE 1.3.0_01 FCS release, so 
Netscape will be able to distribute the JRE on Win32/Linux/Solaris within the 
legal boundaries.

Sean: By default, the JRE will install itself in C:\Program 
Files\JavaSoft\JRE\1.3.0_01.

Comment 12

[Sean Su]

Stanley, what happens if the system doesn't have a c: drive (like some Japanese 
systems)?  Or did you mean that the installer will look for where the "Program 
Files" folder is and install it there?

Comment 13

[drapeau]

Adding Stanley Ho to CC list on this bug so he can respond quickly to Sean Su's
questions.

Comment 14

[Jon Granrose]

George handed the CD with the new bits off to me.  The win32 JVM is at 
http://blues/users/granrose/publish/j2re1_3_0_01-win-i.exe

Comment 15

[Phil Peterson]

Ok, given Stanley's comments about mismatched interfaces, we have to make this
nsbeta3++

Comment 16

[Sean Su]

I just did a quick test against the new bits.  It actually looks in the windows 
registry at:
  key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion
 name: ProgramFilesDir

for the path of where the [Program Files] folder is at.
I'll start updating the windows installer with the new bits.

Comment 17

[Sean Su]

Attachment: patch to install new JRE

Comment 18

[Sean Su]

I've already got a r=sgehani.  Just need a sr=

Comment 19

[Viswanath Ramachandran]

actually i do not know enough about this. can dveditz superreview it.
i think dveditz should be able to superreview stuff (even if he's not
in the mozilla brendan list, this is commercial stuff).
thanks, Vishy

Comment 20

[Daniel Veditz [:dveditz]]

r=dveditz

As a general issue I'm slightly concerned that you require contiguous numbering 
of components. If you didn't this change would have been quite a bit simpler as 
you could simply have left a gap for [Component10].  Since the setup types 
enumerate their components couldn't you just use those lists to know what 
sections to read? Not an issue for this bug, the given patch looks good -- just 
a lot of edits for a fairly simple change :-)

Comment 21

[Sean Su]

fixed.  should be in Thursday's build.

Comment 22

[Sean Su]

It seems to be working in today's build, but it makes the desktop flash whenever 
it draws something in the java applet.  Is this known behavior?

Comment 23

[Grace Bush]

looks ok on build 2000092809MN6

Comment 24

[drapeau]

ssu: are you using an 8-bit display?  If so, then the flashing is known behavior 
and should be put in release notes.  If you happen to know the release note 
meta-bug, lemme know and I'll happily put this info in there.

Comment 25

[Sean Su]

I am indeed using 8bit color mode.  Here is the Release notes bug:
  http://bugzilla.mozilla.org/show_bug.cgi?id=50805

Comment 26

[drapeau]

ssu: cool, thank you very much for the meta-bug number.  I'll update it.

Comment 27

[Asa Dotzler [:asa]]

Reopening to Resolve as Fixed.  Bugs stay resolved until verified on both the
branch and the trunk.

Comment 28

[Asa Dotzler [:asa]]

Resolving as Fixed.  vtrunk keyword is in place requesting trunk verification
before this bug changes state to Verified.  When this is verified on the trunk
vtrunk keyword should be removed and the bug Status should be set to Verified.
Sorry for the spam, just trying to make sure we cover all of our bases here.

Comment 29

[Grace Bush]

verified trunk build 2000111706