put new JRE into trunk and branch builds



19 years ago
14 years ago


(Reporter: granrosebugs, Assigned: granrosebugs)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [rtm need info] need linux installer hackery)



19 years ago
I have a new JRE drop from Sun to put in the branch and trunk.  This does not
fix the Japanese text in Java bug, but I'm told it fixes 7 java plugin specific

no review really possible, leaf has give me the a= as build config owner.

PDT: can I get an rtm++ to check it in?


19 years ago
Keywords: rtm
Whiteboard: [rtm+] JRE in hand, need rtm++
Could it be that this missed the PDT queries because the status whiteboard
contains rtm++ ? If this is the case, I'd suggest to replace "need rtm++" with
something like "need PDT approval". Sorry for my spam...

Comment 2

19 years ago
Gtu Idee Andreas, I've changed it.

Jonathan, due to 57046, and the i18n bug, we'll have to give you yet another 
drop.  However, please put this one on the shelf for now.
Whiteboard: [rtm+] JRE in hand, need rtm++ → [rtm+] JRE in hand, need DPT approval

Comment 3

19 years ago
no spam, you're right.  I thought the queries only looked at what was in the []
but I was mistaken.

Ed: how long do you think for the next drop?  We'd need it by next week at the
Whiteboard: [rtm+] JRE in hand, need DPT approval → [rtm+] JRE in hand, need PDT approval

Comment 4

19 years ago
We need international approval on any JRE drops we take at this point.
Please contact ftang and get his review (approval).
International has had too many regressions to take drops without checking them 

Frank: Please nominate to rtm-plus when you are satisfied that this is an 

Marking rtm need info
Whiteboard: [rtm+] JRE in hand, need PDT approval → [rtm need info] JRE in hand, need PDT approval
This drop will explicity *not* get I18n approval because of the japanese display
bug that is still known. I'd opt for waiting until we have that fix before
checking into the shelf, as each checkin of the jre is going to double the
amount of space in the cvsserver taken up by the jre.exe,v file.

Ed, is there an eta on the japanese display bug fix?
Adding myself to the cc: list.

I agree with Leaf's comments. In addtion, I don't see anything in this report
that illuminates us to where the "win" is here (i.e. How do we benefit from
taking this new drop? What works better or been fixed?).

PDT - I would hold on the ++ for right now.

Ftang and I will be meeting with George this afternoon to discuss.

Comment 7

19 years ago
Yesterday, we were surprised to discover that on 10/12 there
was an interface change in the browser (57046) which causes
a segfault in the Java Plug-in on all Unix platforms.  (I thought
the interface was frozen?)

I just met briefly with George Drapeau, who will probably communicate
the Java 'plan du jour' to the PDT.  We rebuilt the Java Plug-in
last night and plan to test and re-deliver COB Wed, 10/25.  Here
are the only changes planned for this final drop...

   1) Plugin-side adjustment to the interface change (57046) on Unix
   2) Fix for newly-discovered Netscape 4.x plugin regression on Win32
   3) font.properties updates for 1.0 font compatibility in asian+ locales
   4) Updated message bundles

This will be our final Java FCS drop.  If the interface changes again,
there will be no time to respin Java.  Please don't kill Java!  We can
provide an early drop to interested parties to check out prior to the
planned release on 10/25.

Comment 8

19 years ago
updated status whiteboard.

lchiang - is 10/25 going to be soon enough to be able to get this in and still
certify the bits?
Severity: normal → critical
Priority: P3 → P2
Whiteboard: [rtm need info] JRE in hand, need PDT approval → [rtm need info] waiting for new JRE, ETA 10/25

Comment 9

19 years ago
PDT says rtm++ to land the JRE drop that George Drapeau will deliver tomorrow,
Thursday, 10/19.
Whiteboard: [rtm need info] waiting for new JRE, ETA 10/25 → [rtm++] waiting for new JRE, ETA 10/25

Comment 10

19 years ago
just talked with the Sun guys as well, am expecting an email or CD with the new
bits tomorrow, to show up in the builds tomorrow night.
Whiteboard: [rtm++] waiting for new JRE, ETA 10/25 → [rtm++] waiting for new JRE, ETA 10/19

Comment 11

19 years ago
qa contact to shrir.  Shrirang, expect a new JRE build to test.  This will have
the fix for the regression caused by 57046 and the changes mentioned above
except for the Int'l font properties item.  George - pls confirm.  Thanks.
QA Contact: granrose → shrir

Comment 12

19 years ago
Confirming: those two things are correct.  Delivery should be today.  Awaiting 
the "go" from Java Software (looking in my email queue; it may be there even 

Comment 13

19 years ago
granrose - did we get the delivery yet?

Comment 14

19 years ago
George has sent me the link to the new win32 JRE and jung has confirmed they
have the japanese fix.  I can drop those bits in today.

I'm waiting for word on the linux JRE, if I should use the one Ed sent earlier,
or if we're expecting a new one of those as well.

Comment 15

19 years ago
Oops, my bad.  I sent email but failed to update this bug.
No delivery of Linux yet.  It's due today, possibly this morning.  Awaiting word 
from Java Software once they've completed sanity testing on the Linux bits.

Comment 16

19 years ago
I've checked the new win32 JRE into the trunk and the branch and am starting a
win32 build which should be ready in about 90 minutes.
Whiteboard: [rtm++] waiting for new JRE, ETA 10/19 → [rtm++] win32 JRE checked in, waiting for Linux JRE

Comment 17

19 years ago
George: Any update on the Linux JRE?  We'd really like to get a "good build" in
our pocket early next week, and it would be a Bad Thing if this drop is what
we're waiting for.  Can you give us a new ETA?
Jim (always wanting it yesterday) Roskind ;-)

Comment 18

19 years ago
Oops, I'm tardy in updating this bug.  Delivered via xdrive.com to granrose on
10/20/2000.  Lemme know if there are problems.

Comment 19

19 years ago
I've received the linux JRE and placed it on lithium.  I'm doing a branch build
now which should be done in about an hour.

Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 20

19 years ago
cc: gbush. Windows branch build has the correct jre when installed (I checked 
the packaging dates). I cannnot get the jre to work on linux. Seems to install 
on linux but applets do not load. Also, Jonathan, have these bits been updated 
on netcenter, u know? Bcos on linux , I tried to install jre from netcenter and 
I feel that they are the old bits (not sure). Can anyone confirm ? 
Resolution: FIXED → ---

Comment 21

19 years ago
I highly doubt these new Linux JRE bits have been pushed to Netcenter.  At the 
very least, the jre.xpi module needs to be QA's (implicitly through the 
linux installer) before they can be pushed.  I don't believe there has been a 
request to push the new Linux JRE bits out immediately.  From this we can 
deduce that the new Linux JRE bits would likely hit the wire when Netscape 6 is 

Comment 22

19 years ago
In the meantime, is there some way for people to get the linux Java bits in
order to test them?  Installing today's installer build still installs the wrong
Java bits. 

Comment 23

19 years ago
define "wrong java bits".  I ran the stub installer and it installed Java, but
when I went to java.sun.com it told me I needed to download a different JVM from
Netcenter.  Is this a problem with the JRE, the packaging, the build, Netcenter,
or java.sun.com?
Whiteboard: [rtm++] win32 JRE checked in, waiting for Linux JRE → [rtm++] provided JREs checked in, linux not working.

Comment 24

19 years ago
I had some similar problem when I tried the Java plugin with the fix of 57046. 
In my case, it was because my browser was built with debug enabled, whereas the
plugin was not. After I rebuilt the browser with debug disabled, it worked fine.

Comment 25

19 years ago
I just installed the commercial installer with BUILDID 2000102321 and the linux
jre that George gave to you.  I visited java.sun.com and both applets
successfully displayed.

Make sure that the libjavaplugin_oji.so is exactly 349608 bytes in size and has
a checksum of 3203097682.  If it doesn't then you don't have the right java

Comment 26

19 years ago
Problem idenitifed.  Seeking decision on RTM resolution using one of two of the
following recommendations.

The location of libjavaplugin_oji.so has changed in the new bits delivered.

Old relative location:
New relative location:
                             ^^^^^ new!

We were originally asked to make the jre.xpi create a symlink:
  <n6_dir>/plugins/libjavaplugin_oji.so ->

Obviously with the new Linux JRE bits the symlink in the n6 plugins directory is
invalid sice it points at a non-existent file.

Solution #1:
(IMHO, the solution we should go with for RTM since it is lower risk -- read no
code check in required -- than solution #2.)  Have the Linux JRE release folks
repackage the bits with libjavaplugin_oji.so where it originally was (old
relative location as above).

Solution #2:
Change the jre.xpi's install script to make a symlink to the lib in the "ns600"
directory.  This means we'll need a code change and checkin.  Concerned folks
will need to file a *new* bug since this is a new problem (against me I suppose)
and lobby the PDT to allow me to check this in if we go with this solution.
FWIW, this 6 character change is low risk and trivial.

Comment 27

19 years ago
I would like proposal 1.  George: Would the Java folks be able to do this
without changing any of the underlying Java code?

Comment 28

19 years ago
I'll ask the Java Plug-In p-team (equivalent of Netscape's PDT) at their meeting
tomorrow (Wednesday), 11AM.


19 years ago
Blocks: 57046

Comment 29

19 years ago
No surprises here, I vote for Solution #2.  This is a bug in the
installer and not Java Plug-in.  Therefore the installer should be
modified with the simple fix.  I agree with Samir Gehani with regard
to the relative risk of this change in the installer.


19 years ago
Blocks: 56942

Comment 30

19 years ago
So, is this new jre.xpi file available anywhere for testing?  I think that it
really ought to be available somewhere -- this issue blocks a lot more than the
list above would let on.  It's been more than two weeks since any Unix Java
testing has been possible at all with current builds, and I'd imagine that there
are lots of still unknown issues here.

Comment 31

19 years ago
This thrashing is now starting to impact generation of a candidate build.  Since  
the build for today has been spun, I'm going to back this down to an RTM-plus, 
and consider backing out pav's API change, and freezing on the older Java.
This will be discussed at today's PDT meeting at 4pm in the pit.
Whiteboard: [rtm++] provided JREs checked in, linux not working. → [rtm+] provided JREs checked in, linux not working.


19 years ago
Blocks: 56430

Comment 32

19 years ago
Depends on updating the jre.xpi to point to the correct location for 
libjavaplugin_oji.so, bug 57960.

Please note for the record, that the 10/10 linux java plugin bits have this 
problem as well.  Can someone please confirm that 
plugin/i386/ns600/libjavaplugin_oji.so exists in the 10/10 linux java plugin?
No longer blocks: 56430
Depends on: 57960

Comment 33

19 years ago
James Melvin,
Not to be pedantic, but this is *not* an installer bug.  Solution #2 is a
*change request* to the install script because the directory structure change
was not communicated to the installer team when it was made (in the new Linux
JRE bits).

The reason I am raising this point is simple: the .xpi package generation is
done by the commercial build system at Netcsape so in the future any directory
structure changes (in particular ones to libjavaplugin_oji.so) should be
communicated to the Netscape installer and release folks.  Thanks.

Comment 34

19 years ago
You are correct.  It's a change request.

Comment 35

19 years ago
It seems strange that we'd depend on having "ns600" in the path.  Is this the
case on other platforms?  Are we going to have to go through this all over again
when it's 6.01 or 6.5 or whatever instead of 6.0?  Solution 1 (get rid of the
ns600) seems to make more sense if it's possible at this late date.

Comment 36

19 years ago
The reason we need ns600 in the path is to allow for breakages in backwards 
compatability in future releases.  

Comment 37

19 years ago
PDT would like to see the installer patch that brings us up to speed on this 
name change ASAP.  At this late date, we do not wish to wait for a javasoft 
Whiteboard: [rtm+] provided JREs checked in, linux not working. → [rtm need info] provided JREs checked in, linux not working.

Comment 38

19 years ago
update whiteboard, reassign to sgehani.
Assignee: granrose → sgehani
Whiteboard: [rtm need info] provided JREs checked in, linux not working. → [rtm need info] need linux installer hackery

Comment 39

19 years ago
This bug should continue to represent what it was originally filed for: putting
new JRE bits in the builds.  The installer issue is already rtm++'d and is being
tracked by bug 57960.
Assignee: sgehani → granrose


19 years ago
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 40

19 years ago
Since Jon already put the new bits and they are being delivered by the linux
installer this bug can marked fixed but verification depends on bug 57960 being

Comment 41

19 years ago
This is fixed. Both linux and windows new jre bits are in the branch. Keyword: 
vtrunk. I will verify this myself on the trunk.
Keywords: vtrunk

Comment 42

19 years ago
verified that both..windows/linux trunk bits have the latest jre bits(10/27). 

Comment 43

19 years ago
removing vtrunk keyword. sorry for the spam.
Keywords: vtrunk
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.