297160 - Apple patches for Java on Intel Macs

Status: RESOLVED FIXED

(Core Graveyard :: Java: Live Connect, defect)

Description

[Josh Aas]

The attached patches were provided by Apple developers as part of a set of
patches for building and running Firefox on Intel-based Macintoshes. The two
patches attached are the ones related to Java.

I'll let Pedemonte change the summary of this bug to whatever he wants.

Comment 1

[Josh Aas]

Attachment: Apple patch #1

Comment 2

[Josh Aas]

Attachment: Apple patch #2

Comment 3

[timeless]

afaik pedemonte owns an unrelated java module ...

Comment 4

[jhp (no longer active)]

Comment on attachment 185749 [details] [diff] [review]
Apple patch #1

Other than the |cfm_vectors| code, it looks like this patch is update jni.h to
include new JNI features from Java 1.3 and 1.4.  Those should not be marked as
Mac OS X specific.

Josh, did they perhaps mention what the |cfm_vectors| code is about?

And timeless is right;	smichaud would probably know more about this code than
I would (especially the second patch).

Comment 5

[Steven Michaud [:smichaud] (Retired)]

These changes will need to be incorporated into the Java Embedding
Plugin (or more precisely into the MRJ Plugin JEP) -- I shouldn't have
any trouble doing that.

I don't understand Apple's reasoning behind either patch (aside from
the new functions they've added).  I'd be interested to hear whatever
explanation or elaboration they're willing to provide.

The second patch is particularly puzzling -- it's already in the
MRJPlugin JEP!  (Part of it (the removal of the "final" qualifier) has
been present since JEP 0.8.1.  The rest appeared in JEP 0.9.1, and is
connected to a bug fix in LiveConnectNativeMethods.cpp (item #B17 in
that version's (and the current version's) Changes-JEP.txt).)

I don't mind that Apple has copied my code snippets.  (In fact it's
nice to know that they're (apparently) keeping up with the JEP.)  But
I'd like to know why they did so -- there's a (remote) chance that our
uses of the code will conflict.

Comment 6

[Ronnie Misra]

I'm the one who wrote these patches. I didn't mean to include them in my email to Josh; they're not 
ready yet! :)

With these patches I was able to get smichaud's MRJ plugin to work with simple applets, though the 
LiveConnect stuff doesn't work yet. As Steven notes, the second patch is already included in his MRJ 
patches. I had already applied his patch to my tree and so the diffs showed up when I made my patch. 
But maybe now we can get them into the mozilla tree. :)

The changes to jni.h were required because w/o them, I get the following crash:

#0  0xa5f17188 in __cxxabiv1::__unexpected_handler ()
#1  0x274dced4 in JNIEnv_::NewStringUTF (this=0x2bb00fa4, utf=0xbfffb4ea "/Users/builduser/
Library/Logs/Java Console.log") at ../../../dist/include/java/jni.h:1525
#2  0x2b94fda7 in OpenSessionJNI (env=0x2bb00fa4, session=0x288820ec, consolePath=0xbfffb4ea 
"/Users/builduser/Library/Logs/Java Console.log") at Source/MRJSession.cpp:839
#3  0x2b951a60 in MRJSession::open (this=0x288820d0, consolePath=0xbfffb4ea "/Users/builduser/
Library/Logs/Java Console.log") at Source/MRJSession.cpp:1019
...

What's happening here is MRJSession's call out to NewStringUTF is using the wrong offset into the 
JNIEnv_ because it's picking up the wrong jni.h; perhaps there's a better way to fix this, but I couldn't 
think of one.

I'm sorry if I'm not being particularly lucid; I'm still sort of sleepy. If any of this doesn't make sense, let 
me know.

Steven, I also have some patches against JEP and MRJ; should I email you about them?

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> Steven, I also have some patches against JEP and MRJ; should I email
> you about them?

Please do.

By the way, I assume that you're working on a Mac Intel box, and your
changes (the ones that have been posted here and the ones you'll send
to me) were required to get the MRJ Plugin JEP to work in that
environment.  Or is there (also) something else going on?

I also assume that you're building the MRJ Plugin JEP from inside a
Mozilla build.  Are you?  If not, how _are_ you building it?  If so,
which version of Mozilla are you using?  Or are you just using a CVS
pull from the trunk?

And now that we've got hold of you ... what's all the cfm_vectors
stuff about? :-)

Comment 8

[Simon Fraser [no longer active]]

We've had function table issues with jni.h before. IIRC, there's a #define
around some of the functions, so later offsets vary depending on the state of
the #define.

Comment 9

[Ronnie Misra]

Attachment: MRJCarbon diffs for Steven

Comment 10

[Ronnie Misra]

Sorry I've been a little slow to respond; I've been at WWDC all week, and will be there tomorrow as well.

I am working on an Intel-based Macintosh; the attached patches are what I changed to get the 
MRJCarbon plugin to work with my Intel build of Firefox; I've tested a couple of Sun's sample applets 
and they seem to work, but LiveConnect stuff crashes.

I've added my MRJCarbon diffs; they are almost all because JavaEmbedding isn't available on Intel, and 
one small change is because we no longer support statically linking libstdc++.a on Intel.

As for the cfm_vectors, I don't know what it's for! :-P I added those fields to the JNINativeInterface_ 
because I wanted it to match the JNINativeInterface_ defined by the system jni.h (in the JavaVM 
framework); otherwise the function offsets are wrong and I get the crash I pasted above. I'm confused 
that this doesn't cause problems on ppc, because it seems like we should see the same issue there, but 
we don't.

I've filed a bug against the Apple Java team that the Intel jni.h shouldn't have a cfm_vectors array since 
CFM doesn't make sense on Intel, but until and unless this gets fixed, I think we'll need to make sure 
the interfaces match.

I am building the 0.9.2 version of JavaEmbeddingPlugin against a pull of Firefox from the trunk; 
perhaps this wouldn't have been an issue if I'd built against some other version of Firefox.

Again, these patches are quite preliminary; I could very well be doing something silly, but like I said, 
these changes do allow MRJ to work for the applets I've tried, as opposed to just crashing.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

Thanks for the information!

I'm going away for the next few days.  I'll take a closer look when I
get back.

Comment 12

[Josh Aas]

smichaud - is this stuff taken care of? can we close this bug out?

Comment 13

[Steven Michaud [:smichaud] (Retired)]

> is this stuff taken care of?

Yup, long ago (as of the first universal-binary JEP release).

> can we close this bug out?

Close away!