When xpjava.so has been compiled against the jni.h installed during the normal Mozilla build, the test program XPCTest.java will cause a thread dump, within the JNI call GetLongField().
Assign to self, until other help emerges.
Assignee: frankm → drapeau
Status: ASSIGNED → NEW
Component: Java to XPCOM Bridge → OJI
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.
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.
NOTE: Changed primary QA contact person (rest of it remains the same).
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
Re-assigning to Sherry Shen, working on Solaris port of Netscape 6.
Assignee: drapeau → sherry.shen
Status: ASSIGNED → NEW
This does not appear critical to stability of the M15 checkpoint... ..so pushing to M16 to facilitate an M15 branch.
Target Milestone: M15 → M16
Assignee: sherry.shen → edburns
Status: ASSIGNED → NEW
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?
Status: NEW → ASSIGNED
M16 has been out for a while now, these bugs target milestones need to be updated.
Moving to M18
Target Milestone: M16 → M18
Downgrading to P4 and moving out to M19.
Priority: P3 → P4
Target Milestone: M18 → M19
Adding interested parties to interest list of this bug to update the jni.h in mozilla.
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.
Copying a bunch of OJI folks on this bug so that they can look at beard's last comments and try his suggestion. Today.
Oh yeah: Stanley Ho in the Java Plug-In group will probably be interested in this bug as well.
I'll try it on Solaris today.
Updated QA contact and added avm to CC list
QA Contact: rpallath → raghu
Joe: on March 5, you said you would check the Solaris build with jni.h in the Mozilla tree removed. What were the results?
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.
You should get jni.h from your JDK, preferably a Java 2 Standard Edition JDK. Download it from someplace like java.sun.com, point to that include directory, it should be all good. If you're on the Mac, then use the MRJ's include files.
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)?
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.
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. Ed
Summary: Thread dump when compiled against Mozilla jni.h → Remove mozilla's dependence on jni (was: Thread dump when compiled against Mozilla jni.h)
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?
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.
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?
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.
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 "jri.h" /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"
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.
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.
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.
Reassign to Andrew Lyamov
Assignee: edburns → laa
Status: ASSIGNED → NEW
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?
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? 2. 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?
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.
Well, let's see. Following are patches that add Java2 headers to compiler flags and fix jri dependent files respectively.
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".
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.