Remove mozilla's dependence on jni (was: Thread dump when compiled against Mozilla jni.h)



20 years ago
6 years ago


(Reporter: frankm, Assigned: laa)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment, 3 obsolete attachments)



20 years ago
When has been compiled against the jni.h installed during the normal
Mozilla build, the test program will cause a thread dump, within
the JNI call GetLongField().

Comment 1

20 years ago
Assign to self, until other help emerges.


20 years ago
Assignee: frankm → drapeau
Component: Java to XPCOM Bridge → OJI

Comment 2

20 years ago
Reassign to OJI.

There's a larger issue of what that jni.h is doing there in the first place.
Ideally, Mozilla should isolate those modules which rely on Java, and compile
them only when there's a JDK/JVM available; the build can then rely on the
installed header.  Unfortunately, *at least* the following source files outside
of mozilla/java, mozilla/plugin/oji and mozilla/modules/oji depend on jni.h:



20 years ago
Target Milestone: M12

Comment 3

20 years ago
Current workaround for this bug is to blow away the Mozilla version of jni.h
that resides in the Mozilla workspace and use the JDK distribution's version.  A
hacky alternative is to define the symbol "JNI_H", which prevents the inclusion
of symbols in the Mozilla jni.h include file.  Neither of these are a real
answer, though.


20 years ago
Target Milestone: M12 → M14

Comment 4

20 years ago
Not going to make it for this milestone.  Will look at LiveConnect code's usage
of jni.h file, see why it's necessary if the JVM is loaded as an XPCOM service.
Since it's not stopping functionality right now for LiveConnect or OJI, will
move this to a later milestone when there's more time to work on it.


20 years ago
QA Contact: leila.garin → rpallath

Comment 5

20 years ago
NOTE: Changed primary QA contact person (rest of it remains the same).

Comment 6

20 years ago
Not going to risk making this change for M14, since much larger problems loom
with OJI and need to be solved first.  Moving to M15.
Target Milestone: M14 → M15

Comment 7

20 years ago
Re-assigning to Sherry Shen, working on Solaris port of Netscape 6.
Assignee: drapeau → sherry.shen


19 years ago

Comment 8

19 years ago
This does not appear critical to stability of the M15 checkpoint... pushing to M16 to facilitate an M15 branch.
Target Milestone: M15 → M16

Comment 9

19 years ago
Taking ownership
Assignee: sherry.shen → edburns

Comment 10

19 years ago
Reviewed the status.  The problem is that nsISecureEnv depends on
  having a 1.1.x level jni.h in the tree.  If you don't have a 1.1.x
  level jni.h in the tree, LiveConnect will not build.  Can we remove
  the compile time dependency on java from LiveConnect?


Comment 11

19 years ago
M16 has been out for a while now, these bugs target milestones need to be 

Comment 12

19 years ago
Moving to M18
Target Milestone: M16 → M18

Comment 13

19 years ago
Downgrading to P4 and moving out to M19.
Priority: P3 → P4
Target Milestone: M18 → M19

Comment 14

19 years ago
Adding interested parties to interest list of this bug to update the jni.h in

Comment 15

19 years ago
I'm all for blowing away the mozilla/sun-java directory. I just found that the 
jni.h there causes crashes when used with MRJ. There's something definitely 
incompatible with those header files. I will run a Mac build with mozilla/sun-
java removed to verify that this works. If others could do so on their platforms, 
we can then safely CVS remove that directory.

Comment 16

19 years ago
Copying a bunch of OJI folks on this bug so that they can look at beard's last
comments and try his suggestion.  Today.

Comment 17

19 years ago
Oh yeah: Stanley Ho in the Java Plug-In group will probably be interested in
this bug as well.

Comment 18

19 years ago
I'll try it on Solaris today.

Comment 19

18 years ago
Updated QA contact and added avm to CC list
QA Contact: rpallath → raghu


18 years ago
Blocks: 70847

Comment 20

18 years ago
Joe: on March 5, you said you would check the Solaris build with jni.h in the 
Mozilla tree removed.  What were the results?

Comment 21

18 years ago
Need to decide from where to include the right jni.h, etc., since at least
LiveConnect seems to need reference to JNIEnv which is defined in jni.h. 

Comment 22

18 years ago
You should get jni.h from your JDK, preferably a Java 2 Standard Edition JDK.
Download it from someplace like, point to that include directory,
it should be all good.  If you're on the Mac, then use the MRJ's include files.

Comment 23

18 years ago
We may hack it to compile, but what about a fix that can be checked in, so that
mozilla can be built with reference to the right jni.h (for all components that
need jni.h)?

Comment 24

18 years ago
I think the best solution is to use the JDK that you have with your system.  My
opinion is to remove the JDK-specific headers from the Mozilla repository (as, I
believe, Patrick is suggesting), and when you build, you make sure you have an
MRJ or JDK around.

Comment 25

18 years ago
I agree with George.  The Mozilla build system and build instructions should 
specify that you have to have JDK installed, with JDKHOME set to whatever.  The 
build system will pick that up.

Of course, we'll probably have to make it so you can build without having a JDK 
around to keep non java-fans happy.  Perhaps you can add some options to 
configure,  like  --disable-liveconnect.


Comment 26

18 years ago
Changed subject.
Summary: Thread dump when compiled against Mozilla jni.h → Remove mozilla's dependence on jni (was: Thread dump when compiled against Mozilla jni.h)

Comment 27

18 years ago
Status on this bug?  Now is as good a time as any to clean out the bug, and
70847 can be closed when this one is closed.  I like the idea of the
"--disable-liveconnect" configure option; do you have the ability to prototype
this, Ed, or do you require help on this one?

Comment 28

18 years ago
Hi George,

With bug 76677 and bug 76921 I haven't had much time to consider this.  I think 
it's pretty non-trivial.

Comment 29

18 years ago
Tried on mozilla08, and it did not have the problem. I could toggled between
Back and Forward buttons without problems.
Therefore, it seems the problem was introduced between 08 and 08.1.

Comment 30

18 years ago
Tried to build mozilla without sun-java on Solaris, (removed sun-java dir, and
copied bunch of java header files from java sdk package (jni.h etc.)). But found
out that the Java Runtime Interface headers are still needed (jri.h, etc, needed
by oji nsIPlugin), which were not found in the java sdk include. Where should
JRI headers come from? For the time being, copied the ones in sun-java to
dist/include and see what else may be missing. By the way, the JNI headers for
java sdk are not compatible with the JRI headers in sun-java.
Patrick, how's your build on Mac without sun-java?

Comment 31

18 years ago
Joe: JRI is old Netscape stuff, before JNI was really stable and worth using.
Whatever is using JRI should either probably be taken out as well, or identified
and replaced with the corresponding JNI calls.

What exactly was using JRI that broke?  A transcript of your build would help.

One of the engineers in St. Petersburg is working on this, by the way.

Comment 32

18 years ago
Currently, jri.h is included in the following header files, and I guess in most
cases it can be either removed or replaced with jni.h:

/include/npapi.h, line 45 -- #include "jri.h" /* Java Runtime Interface */
/include/npupp.h, line 45 -- #include "jri.h"
/modules/oji/public/nsIJRIPlugin.h, line 37 -- #include "jri.h"
/modules/plugin/nglsrc/ns4xPluginStream.h, line 29 -- #include "jri.h" // XXX
should be jni.h
/modules/plugin/nglsrc/ns4xPluginInstance.h, line 36 -- #include "jri.h"
/modules/plugin/public/nsIJRILiveConnectPlugin.h, line 54 -- #include "jri.h"
/modules/plugin/public/nsIJRILiveConnectPlugInstPeer.h, line 55 -- #include
/modules/plugin/public/nsPluginDefs.idl, line 362 -- #include "jri.h"
/modules/plugin/public/nsPluginDefs.idl, line 363 -- #include "jri.h"
/plugin/oji/MRJ/plugin/Source/npmac.cpp, line 46 -- #include "jri.h"

Comment 33

18 years ago
For example, to get rid of the reference of jri.h in nsIJRIPlugin.h, I removed
its include in nsjvm.h and changed the reference in nsJVMManager.h from JRIEnv
to JNIEnv (that was what it should have been), and then oji module compiled fine
without jri.h.

Comment 34

18 years ago
At the very least, can we modify the makefiles so that jni.h is removed from 
dist\include after the files that depend on it are built?  This is Igor's idea.

Comment 35

18 years ago
The "jni.h shouldn't be in dist\include" bug impacts pluglets.  Ashu,
Igor and I worked on this a bit today, and I discovered that
oji\public\nsjvm.h includes nsIJRIPlugin.h.

Comment 36

18 years ago
Any file that says

#include "jni.h"

should say

#include <jni.h>

Here is the list of such files.

Anyone want to generate a patch that does this?

include "jni.h"
/ef/Runtime/NativeMethods/Jni.cpp, line 22 -- #include "jni.h"
/ef/Runtime/NativeMethods/md/x86/x86NativeMethodStubs.cpp, line 25 -- 
#include "jni.h"
/java/dom/src/nsIJavaDOM.h, line 28 -- #include "jni.h"
/java/dom/src/nsJavaDOMImpl.h, line 4 -- #include "jni.h"
/java/dom/jni/javaDOMGlobals.h, line 25 -- #include "jni.h"
/java/plugins/jni/ByteRanges.h, line 26 -- #include "jni.h"
/java/plugins/jni/PlugletOutputStream.h, line 24 -- #include "jni.h"
/java/plugins/jni/org_mozilla_pluglet_mozilla_PlugletStreamInfoImpl.h, line 22 -
- #include "jni.h"
/java/plugins/jni/PlugletTagInfo2.h, line 24 -- #include "jni.h"
/java/plugins/src/Pluglet.h, line 24 -- #include "jni.h"
/java/plugins/src/PlugletEngine.h, line 24 -- #include "jni.h"
/java/plugins/src/PlugletViewMotif.h, line 24 -- #include "jni.h"
/java/plugins/src/PlugletInputStream.h, line 24 -- #include "jni.h"
/java/plugins/src/PlugletPeer.h, line 24 -- #include "jni.h"
/java/plugins/src/PlugletView.h, line 24 -- #include "jni.h"
/java/plugins/src/PlugletLoader.h, line 23 -- #include "jni.h"
/java/plugins/src/PlugletManager.h, line 24 -- #include "jni.h"
/java/plugins/src/PlugletStreamInfo.h, line 24 -- #include "jni.h"
/java/plugins/src/PlugletStreamListener.h, line 24 -- #include "jni.h"
/java/plugins/src/Registry.h, line 23 -- #include "jni.h"
/java/plugins/src/PlugletFactory.h, line 24 -- #include "jni.h"
/java/plugins/src/PlugletViewWindows.h, line 25 -- #include "jni.h"
/java/webclient/src_moz/wcIBrowserContainer.h, line 29 -- #include "jni.h"
/java/xpcom/java/src/bcIIDJava.h, line 26 -- #include "jni.h"
/java/xpcom/java/src/bcJavaMarshalToolkit.h, line 29 -- #include "jni.h"
/java/xpcom/java/src/bcJavaGlobal.h, line 25 -- #include "jni.h"
/java/xpcom/java/src/bcJavaStub.h, line 26 -- #include "jni.h"
/java/xpcom/java/src/bcIJavaStubsAndProxies.h, line 26 -- #include "jni.h"
/java/pluggable-jvm/wf/src/plugin/netscape4/jri_md.h, line 37 -- 
#include "jni.h"
/java/pluggable-jvm/wf/src/plugin/netscape4/npupp.h, line 44 -- #include "jni.h"
/js/jsd/java/jni_stubs.c, line 28 -- #include "jni.h"
/js/jsd/java/jsdjava.h, line 44 -- #include "jni.h"
/js/src/liveconnect/jsj_private.h, line 70 -- #include "jni.h" /* Java Native 
Interface */
/js/src/liveconnect/jsjava.h, line 51 -- #include "jni.h" /* Java Native 
Interface */
/js/src/liveconnect/_jni/netscape_javascript_JSException.h, line 2 -- 
#include "jni.h"
/js/src/liveconnect/nsILiveconnect.h, line 46 -- #include "jni.h"
/js/src/liveconnect/nsISecureLiveconnect.h, line 47 -- #include "jni.h"
/lib/libmocha/lm_applt.c, line 48 -- #include "jni.h"
/lib/libmocha/lm_embed.c, line 39 -- #include "jni.h"
/lib/libmocha/lm_init.c, line 51 -- #include "jni.h"
/modules/oji/public/nsIJVMManager.idl, line 27 -- #include "jni.h"
/modules/oji/public/nsIJVMPlugin.h, line 38 -- #include "jni.h"
/modules/oji/public/nsILiveConnectManager.h, line 35 -- #include "jni.h"
/modules/oji/public/nsISecureEnv.h, line 29 -- #include "jni.h"
/modules/oji/public/nsISecureJNI.h, line 29 -- #include "jni.h"
/modules/oji/public/nsISecureJNI2.h, line 29 -- #include "jni.h"
/modules/oji/public/nsIJVMPluginInstance.idl, line 35 -- #include "jni.h"
/modules/oji/src/jvmmgr.h, line 27 -- #include "jni.h"
/modules/oji/src/lcglue.h, line 27 -- #include "jni.h"
/modules/oji/src/nsJNI.cpp, line 27 -- #include "jni.h"
/modules/oji/src/nsJVMManager.h, line 30 -- #include "jni.h"
/modules/oji/tests/src/JNI/include/JNIEnvTests.h, line 31 -- //#include "jni.h"
/modules/plugin/public/nsILiveConnectPlugInstPeer.h, line 43 -- 
#include "jni.h" // standard JVM API
/modules/plugin/public/nsILiveConnectPlugin.h, line 42 -- #include "jni.h" // 
standard JVM API
/plugin/oji/MRJ/plugin/Source/JavaMessageQueue.h, line 29 -- #include "jni.h"
/plugin/oji/MRJ/plugin/Source/MRJFrame.h, line 36 -- #include "jni.h"
/plugin/oji/MRJ/plugin/Source/JSEvaluator.h, line 31 -- #include "jni.h"
/plugin/oji/MRJ/plugin/Source/LiveConnectNativeMethods.h, line 30 -- 
#include "jni.h"
/plugin/oji/MRJ/plugin/Source/MRJConsole.h, line 38 -- #include "jni.h"
/plugin/oji/MRJ/plugin/Source/MRJContext.h, line 32 -- #include "jni.h"
/plugin/oji/MRJ/plugin/Source/MRJMonitor.h, line 33 -- #include "jni.h"
/plugin/oji/MRJ/plugin/Source/MRJSession.h, line 36 -- #include "jni.h"
/plugin/oji/MRJ/plugin/Source/PluginNew.cpp, line 32 -- #include "jni.h"
/embedding/browser/activex/src/plugin/LegacyPlugin.cpp, line 24 -- 
#include "jni.h"
/sun-java/stubs/include/interpreter.h, line 34 -- #include "jni.h"
/sun-java/stubs/include/jritypes.h, line 31 -- #include "jni.h"

Comment 37

18 years ago
Reassign to Andrew Lyamov
Assignee: edburns → laa

Comment 38

18 years ago
I've seen no comments or visible progress on this bug in two weeks.  Andrew, do
you have any comments to report here, or progress?

Comment 39

18 years ago
1. I don't see the reason of such changes ("" to <>). Isn't it enough to add
-I$(JDK_HOME)/include -I$(JDK_HOME)/include/$(OSTYPE) flags?

One possible solution of "no JDK" situation is to drop MOZ_OJI flag and thus
avoid OJI and LiveConnect modules building. Plugins and content/html modules
will need some tuning though. Is that acceptable? And what functionality loss
is allowed?

Comment 40

18 years ago
Andrew: No, I'm afraid that the suggestion in your second point is not
acceptable.  Please think of the problem this way: the jni.h file that is
currently in Mozilla's code base is terribly out of date, and I want all of the
files that depend on it to have their dependencies either updated or removed. 
This is a good opportunity to clean up dead code.  If there is code that
includes jni.h but does not need to, please identify those files and attach
patches for removing the references.  For JRI headers (which no longer apply to
this browser, they come from the old 4.X browser), please identify those and
attach patches to either stop building those files or remove the references to
JRI, or suggest a plan of action that we can follow to fix the offending code.

For the remainder of the browser that has a legitimate dependency on jni.h,
please assume a Java 2 jni.h and further assume that this jni.h will come from a
JDK that the developer has installed on his/her computer.  In the future, jni.h
will not be included in the Mozilla codebase.

Is this clear enough?  I don't want to hear whether it is *difficult*, I just
want to hear from you whether this is a clear enough direction.  If it is
difficult, fine, but that is a separate matter.

To answer your first point, I don't know the answer and Ed Burns is away for one
week.  Perhaps somebody else on the interest list for this bug can supply a reason.


Comment 41

18 years ago
Well, let's see. Following are patches that add Java2 headers to compiler flags
and fix jri dependent files respectively.

Comment 42

18 years ago
Posted patch Patch to add Java headers (obsolete) — Splinter Review

Comment 43

18 years ago


18 years ago
QA Contact: raghu → avm


18 years ago
Attachment #39157 - Attachment is obsolete: true


18 years ago
Attachment #39158 - Attachment is obsolete: true

Comment 45

16 years ago


16 years ago
Attachment #40289 - Attachment is obsolete: true


9 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.