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 bugs. no review really possible, leaf has give me the a= as build config owner. PDT: can I get an rtm++ to check it in?
Status: NEW → ASSIGNED
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...
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
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 latest.
Whiteboard: [rtm+] JRE in hand, need DPT approval → [rtm+] JRE in hand, need PDT approval
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 first. Frank: Please nominate to rtm-plus when you are satisfied that this is an improvement. 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.
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.
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
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
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
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
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 now).
granrose - did we get the delivery yet?
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.
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.
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
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? Thanks, Jim (always wanting it yesterday) Roskind ;-)
Oops, I'm tardy in updating this bug. Delivered via xdrive.com to granrose on 10/20/2000. Lemme know if there are problems.
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. resolved/fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
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 ?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Shrirang, 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 released.
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.
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.
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.
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 plugin!
Problem idenitifed. Seeking decision on RTM resolution using one of two of the following recommendations. Problem: -------- The location of libjavaplugin_oji.so has changed in the new bits delivered. Old relative location: jre-image-i386/plugin/i386/libjavaplugin_oji.so New relative location: jre-image-i386/plugin/i386/ns600/libjavaplugin_oji.so ^^^^^ new! We were originally asked to make the jre.xpi create a symlink: <n6_dir>/plugins/libjavaplugin_oji.so -> <n6_dir>/plugins/java2/plugin/i386/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.
I would like proposal 1. George: Would the Java folks be able to do this without changing any of the underlying Java code?
I'll ask the Java Plug-In p-team (equivalent of Netscape's PDT) at their meeting tomorrow (Wednesday), 11AM.
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.
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.
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.
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?
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.
You are correct. It's a change request.
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.
The reason we need ns600 in the path is to allow for breakages in backwards compatability in future releases.
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 respin.
Whiteboard: [rtm+] provided JREs checked in, linux not working. → [rtm need info] provided JREs checked in, linux not working.
update whiteboard, reassign to sgehani.
Assignee: granrose → sgehani
Status: REOPENED → NEW
Whiteboard: [rtm need info] provided JREs checked in, linux not working. → [rtm need info] need linux installer hackery
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
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
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 fixed.
This is fixed. Both linux and windows new jre bits are in the branch. Keyword: vtrunk. I will verify this myself on the trunk.
verified that both..windows/linux trunk bits have the latest jre bits(10/27). VERIFIED.
Status: RESOLVED → VERIFIED
removing vtrunk keyword. sorry for the spam.
You need to log in before you can comment on or make changes to this bug.