13848 - build MRJ plugin as part of the standard mozilla build process.

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect, P3)

Description

[Paul Wyskoczka]

Java will not be enabled if the user does not manually configure the system
after installing seamaonkey. See the following link for instructions
http://www.mozilla.org/oji/MRJPlugin.html .  So attempting to start an applet
will fail with an error indicating that Java is not enabled.  The installation
program should setup MRJ for the user as the Windows installer does.

Comment 1

[Sean Su]

reassigning this to Samir.

Comment 2

[Samir Gehani]

If we ship MRJ with Nav 5 it will probably be done in the form of a wrapped
installer rather than a .xpi. The .xpi install script that wraps the native
installer could take care of this if the native installer fails to do so. This
is not my bug but it is not clear who to reassign this to.

It is clear that we need to know if we are shipping with MRJ. We need this info
for both commercial and mozilla.

ekrock,
Assuming you are the product manager for pluggable Java, could you shed some
light on the afore mentioned?

Eventually I believe this will fall in the hands of the release team with some
support from the XPInstall team for the actual MRJ .xpi wrapper install script.
Hence cc'ing jj.

Comment 3

[Samir Gehani]

The correct person needs to own this bug. I believe I am not the correct person.
Reassiging to ekrock to get the ball rolling. Specifically we need to know if we
will be shipping MRJ with 5.0.

ekrock,
If you feel this is not your bug, please reassign as deemed appropriate.

Comment 4

[leger]

WE should release note for M11.

Comment 5

[ekrock's old account (dead)]

Here's the deal:

1) We will not "bundle" or "distribute" the MRJ binary with any
Mozilla/Nav5-based browser (read: neither mozilla nor commercial nor anybody
else's derivative).  Reason: an OJI-ready MRJ already exists on all the MacOS
versions we support.
2) Thus, it is *CRITICAL* that Nav5 successfully detect the presence of MRJ and
use that to enable Java.  Indeed, this is the only way we'll get Java to work
with Nav5 on the Mac.  So, fixing this bug is the highest priority Java work for
the Mac.  We cannot ship the product while requiring users to manually configure
Java.

I don't know off the top of my head which engineer is currently handling this
(Samir? Patrick?).  Whichever engineer is responsible for getting OJI to work on
the Mac should accept this bug.  Reassigning bug back to Samir for now.  Samir,
if you're not the right engineer, please figure out who is and give it to that
person. cc:ing beard who might know. Thanks!

Comment 6

[Cathleen]

This doesn't sound like an installer problem anymore, since we do not need to
install Mac Java plugin.

Rick or Patrick, are you the ones taking care of mac Java plugin?

Comment 7

[rickg]

Patrick -- can you please take a look at this for me?

Comment 8

[Patrick C. Beard]

We should just always try to load the MRJ OJI plugin. It will detect whether or
not MRJ is installed (and it almost always will be on modern systems we run on).
If the plugin exists, then we can enable Java automatically.

Comment 9

[Samir Gehani]

*** Bug 18470 has been marked as a duplicate of this bug. ***

Comment 10

[Paul Wyskoczka]

in the 2000010308 build, moving the plugins into the plugins folder does not enable java.

Comment 11

[Andrew Thompson]

Just tried to get Java going in M13, with no sucess. Here's my setup:
Mac OS 9.0
Mozilla M13
MRJ 2.2 (new release of Java from Apple this week)

Result: No go. Java applets don't load, instead only a grey area is displayed.

For clarity, I'm following the instructions from here:
http://www.mozilla.org/oji/MRJPlugin.html

Which means I put the plugin into the Extensions Folderr in the System Folder. I
have no idea if these instructions are still valid or not. I suspect Patrick
Beard ([e-mail]) will know about this...

Comment 12

[ekrock's old account (dead)]

FYI: There's a possibly-related problem, bug #23672, in which even if the Sun 
OJI plug-in is loaded on Win32, the JDK 1.3 JVM doesn't work with post-M12 
builds due to internal changes by us to the plug-in API. Not sure if this is 
relevant on the Mac, which uses an older release level JDK from Apple (the MRJ).

If 23672 also occurs on the Mac with the MRJ, then even if you get the basic 
plug-in recognition problem solved, Java still won't run on the Mac.

Adding av and drapeau (FYI only) to cc: list. Andrei, if 13848 in fact depends 
on 23672, would you please mark the dependency?

Comment 13

[drapeau]

The MRJ Plugin should work now; [e-mail], can you verify, please?  I
believe you have the latest working Plugin from [e-mail], and I
believe [e-mail] has or will soon put the latest binaries on the
Mozilla ftp site (ftp://ftp.mozilla.org/pub/OJI/).

Comment 14

[Paul Wyskoczka]

I did get the new plugins and they worked but the old one are still up on Mozilla.

Comment 15

[Jim Roskind]

beta1 nomination.  This is blocking MRJ (Java on the mac).  We have to decide if
we can get this done for beta.  IF not, then we should mark this PDT-, and to
the same to the bug that is depending on this one.
Can anyone give us status on this bug? How far are you from a fix?  We need
dates in the status whiteboard if we are going to have a shot at taking this as
a PDT+ bug.

Comment 16

[J.J. Enser]

Based on the comments from Drapeau & Paw from 2/29, it seems like we have a 
working solution.

The working bits need to get to me one way or the other before beta1. Leaf 
doesn't have them.

The easiest for me, if the bits won't changed by then, is to have the 2 files 
needed sitting on the Release Build mac that runs the daily verification build 
and packages the installer. If this is ok, please someone send them my way.

Later on, we should have either:
1- a static url where new bits get pushed whenever they change, and where my 
automation will grab them from.
2- the MRJ plugin source checked in in cvs.mozilla.org, and built as part of the 
standard build script, like any other Mac project.

My preference goes to [2] as it makes the maintenance easier and also reduces 
dependencies/reliability on binary files.

Comment 17

[Phil Peterson]

PDT+. w/b minus on 3/3

Comment 18

[J.J. Enser]

new drop received from Loki. posted on mozilla.org, and temporarily added to the 
Mac packaging automation, until it gets built from the mozilla tree.

Comment 19

[Jim Roskind]

Hopefully the 3/3 drop fixed this... but for now, we're putting this to PDT- as 
per the whiteboard warning.

Comment 20

[Andrew Thompson]

This is now working in the nightlies for the first week of March 2000.
Do we want to leave this here as a placeholder bug for 'Java on the Mac should 
work' until after beta1 is out?

Comment 21

[Paul Wyskoczka]

This is now working on the Mac, so I think it can be resolved and verified.

Comment 22

[Grace Bush]

This is not working on MacOS 8.5 or 8.51
MRJ plugins are there but applets do not work

Comment 23

[Paul Wyskoczka]

Looks like what is happening  is that is works on MacOs 9.0  but not on 8.6,  8.5 and 8.5.1.  Loki can you check this out?

Comment 24

[modgock]

I build and run on 8.6US and have noted no problems.  The other item of  version 
on my systems:
MRJ2.2
CW5.3
(yosemite g3 - 400mhz)

Comment 25

[J.J. Enser]

No, this bug is about integrating the MRJ plugin to the regular mozilla build 
script. Adjusting bug summary to clarify.

The bug that tracked the "packaging" of MRJ plugin with the daily build is 29549, 
and has been marked fixed, then verified.

Comment 26

[J.J. Enser]

please disregard my lasst comment, I was a train behind :-(

Grace, do you have MRJ (Macintosh Runtime for Java) installed on your 8.5 or 8.51 
system ? I'm not sure if this part of the default OS installation.

Comment 27

[Paul Wyskoczka]

The problem here is that the machines did not have mrj 2.2.  Most had mrj 2.0.  Once we upgraded them,  applets loaded fine.

Comment 28

[J.J. Enser]

Should we release note the fact that users of MacOS 8.5 to 8.6.1 (?) must upgrade 
from MRJ 2.0 to MRJ 2.1 (2.2 recommended?) in order to run Java applets with 
mozilla ?

Comment 29

[Paul Wyskoczka]

That's a good idea, Grace.  Let's add it to the beta1 release notes.

Comment 30

[Grace Bush]

done- added to bug 29686

Comment 31

[J.J. Enser]

Loki, for most accuracy, can you confirm which version or NRJ is required? 
recommended?

Comment 32

[Andrew Thompson]

Here are the default installed MRJ versions for recent Mac OS releases.
(I'm about 90% sure these are right)

8.0 = MRJ 1.5 (Java 1.0.2)
8.5 = MRJ 2.0 (Java 1.1.3)
9   = MRJ 2.1.4 (Java 1.1.7) 

*BUT* Mac OS 9 includes software auto update, so most Macs that are
attached to the internet will have automatically been upgraded to:

9 + auto-update = MRJ 2.2 (Java 1.1.8.)

If I had to guess, I'd say 8.1 = MRJ 2.0.X and 8.6 = 2.1.X

So *if* you require MRJ 2.1 to run, then yes, 2.1 required, 2.2 recommended is 
a good thing to have in the release notes...

Comment 33

[modgock]

Require 2.2 as apparently we were having problems in the past couple days with 
2.1.x and 2.0.x installs of it working with the plugin.  I'm indeed compiling 
against the JNILib that comes with the 2.2MRJSDK.

Comment 34

[J.J. Enser]

Thanks for the precision, Loki.
Updated Beta 1 Release Notes bug #29686 accordingly.

Comment 35

[Patrick C. Beard]

Are you aware of weak linking? You can weak link against a library, and if the 
library doesn't support the API, then the entry point will be NULL. For example, 
you can test for this with:

if (&ImportedFunction != NULL) {
  ImportedFunction();
}

This should permit you to work with older versions of MRJ, which is highly 
desirable.

Comment 36

[ekrock's old account (dead)]

Would the change Patrick suggests enable support of the 2.0 MRJ in MacOS 8.5? If 
so, how much work would it entail? It would be great if our browser could work 
with out-of-the-box MacOS 8.5.

Comment 37

[Patrick C. Beard]

This shouldn't take long at all, it was working with MRJ 2.1 all along. You just 
have to guard your usage of new features. Examples exist in the code already. 
Changing component to OJI.

Comment 38

[modgock]

i make use of no new 2.2 features so my recommendation was not based on a code 
issue; i recommend 2.2 as it is what i build and test against and thereby know it 
to work against.  compounding this was the earlier flap that machines with 2.0.x 
installed were now not running the plugin for whatever reason until 2.2 was 
installed.

Comment 39

[J.J. Enser]

Do we have an ETA on when this will be part of the regular mozilla build ?

Patrick, do you own or can you help setting this up ? Then I guess we can do what 
you suggested (weak link) to improve compatibility with MRJ <2.2

Comment 40

[modgock]

i'll do a build right now weak importing the JNILib as well as JManagerLib and 
mail that MRJInABox off to jj and paw.  could you give it a try on a non MRJ2.2 
machine when you have a chance?  danke, loki.

Comment 41

[modgock]

removing modgock from the cc list, adding loki-sun instead; as a side note, weak 

link initially failed 2.0 test today - sent one last try to paul and jean 

tonight.

Comment 42

[loki der quaeler]

two builds of weak importing JNILib and JManagerLib have both failed on mrj 2.0; 

as there's no 2.2 specific code that's been added, beard's code modification 

suggestion has no application to this problem it would seem.  i've no good 

rational solution - any ideas patrick?

Comment 43

[Patrick C. Beard]

MRJ 2.0 is too old, I agree. I'd start with MRJ 2.1. I have definitely had 
success with versions starting with MRJ 2.1.

Comment 44

[J.J. Enser]

Adding dependency on 32933 (Update Mac Build to Universal Headers 3.3)

According to Patrick ([e-mail]), there are 2 or 3 projects that need to 
be added to the perl script.
Also, building 'MRJPlugin.jar' will require the addition of java tools to the 
default build system.

Patrick will add a environment variable to the build script 
(BuildNGLayout[Debug].pl) to conditionally build the required projects, and we'll 
flip the switch after we have resolved the dependencies and made the necessary 
changes on the build environment.

-- Not sure why this is assigned to drapeau@sun, but as long as Patrick or George 
are on this...

Comment 45

[drapeau]

jj: I think I'm assigned the bug because it's in the OJI component, so by
default I would become the assignee.  It's cool with me if Patrick is kind
enough to take the bug.  Whatever gets it taken care of, that rocks.

This is great news.

Comment 46

[loki der quaeler]

freeing george -- this really should be assigned to beard, but i'll free george 
from this albatross..

Comment 47

[J.J. Enser]

Patrick, I thought this was yours for a while ?!? There is a depedency on 32933 

(univ. headers 3.3), which you also own.

Let me know if I can help.

Comment 48

[leger]

Putting on beta2 keyword radar since this was "plus for beta2" during beta1 
triaging

Comment 49

[J.J. Enser]

Loki, now that you seem to own this bug, what do we need to proceed ?

We have updated the univ. headers to 3.3.1, which was one of the requirements. 
However, It looks like we still need to add some CodeWarrior java tools to the 
build environment if we want to be able to build the plugin the way it is now.
What's your position on this?
See below the missing access paths warnings I get when opening MRJInABox.mcp

The following access path in target “MRJInABox” cannot be found:
{Project}::MRJSDK:CIncludes:

The following access path in target “MRJInABox” cannot be found:
{Project}::MRJSDK:Libraries:

The following access path in target “MRJInABox” cannot be found:
{Compiler}:Java Support:VM_Support:MRJ_Support:Libraries:

The following access path in target “MRJInABox” cannot be found:
{Compiler}::CodeWarrior MPW:Interfaces&Libraries:Libraries:SharedLibraries:

The following access path in target “BackwardAdaptor” cannot be found:
{Compiler}::CodeWarrior MPW:Interfaces&Libraries:Libraries:SharedLibraries:

The following access path in target “BackwardAdaptor” cannot be found:
{Project}::MRJSDK:Libraries:

The following access path in target “MRJInABox (4.X)” cannot be found:
{Project}::MRJSDK:CIncludes:

The following access path in target “MRJInABox (4.X)” cannot be found:
{Project}::MRJSDK:Libraries:

The following access path in target “MRJInABox (4.X)” cannot be found:
{Compiler}:Java Support:VM_Support:MRJ_Support:Libraries:

The following access path in target “MRJInABox (4.X)” cannot be found:
{Compiler}::CodeWarrior MPW:Interfaces&Libraries:Libraries:SharedLibraries:


Please confirm what needs to be done to get this fixed.

Also, now that we have a jar packaging tool added to MacPerl, we need to update 
the build script to generate 'MRJPlugin.jar'. Where does the content of this jar 
come from? Is it static or does it need to be rebuilt every time?

M16 is quickly approaching ;-)

Comment 50

[loki der quaeler]

there's a script that patrick wrote which builds an mcp from the project xml file 
that he also checked in; that xml file has the correct access paths which should 
clear up all of the below.
i suppose the build script should invoke the applescript (called 
"MRJPlugin.import" and in the same directory as the old project file and the xml) 
prior to invoking the build.
at the moment, i'm unable to get anything to build, so perhaps patrick should 
take this bug over.

Comment 51

[Patrick C. Beard]

Taking bug.

Comment 52

[Patrick C. Beard]

Got it.

Comment 53

[leger]

Putting on [nsbeta2+] radar for beta2 fix.

Comment 54

[Patrick C. Beard]

I've checked in changes to the Mac build system perl script

mozilla/build/mac/NGLayoutBuildList.pm v1.506

To turn it on in the build, simply uncomment line #2054.

Comment 55

[Paul Wyskoczka]

Added [e-mail] and [e-mail] to the cc list.  

Comment 56

[leger]

Need this fixed ASAP.  Putting on dogfood+ radar.  Blocking QA from doing any 
test in thi area.

Comment 57

[Patrick C. Beard]

ETA is this can be switched on immediately, after the tinderbox tools are 
updated. I need assistance from a build engineer to make sure this is done 
carefully.

Comment 58

[J.J. Enser]

Patrick, see Leaf/Granrose to get the build env. updated on the 5 Mac 
tinderboxen.
If need be, I can help using Timbuktu while I'm away.

Comment 59

[Paul Wyskoczka]

I just checked the latest build 2000052312 and the plugins are still not be 
built on a daily basis.  Current build is 3/24/2000

Comment 60

[Patrick C. Beard]

I can enable this today (5/30/2000).

Comment 61

[Jim Roskind]

Cleaned up status whiteboard, and added ETA 5/31 as indicated in  comment of 
5/30.

Comment 62

[Paul Wyskoczka]

Changed qa contact to [e-mail]

Comment 63

[Patrick C. Beard]

Changes checked in for this.

Comment 64

[J.J. Enser]

Build automation updated to include new MRJ Plugin.
To be verified against next release build (2000060208)

Comment 65

[shrirang khanzode]

This is fixed. MRJ plugin is being built again in today's build. Marking 
VERIFIED. (2000060208)