Move JavaXPCOM bridge from XULRunner core to separate extension



Core Graveyard
Java to XPCOM Bridge
8 years ago
3 years ago


(Reporter: Jacek Pospychala, Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



8 years ago
As discussed at
let's move JavaXPCOM from core to separate extension. One of the most interesting benefits of that move is that it would be possible to re-use system-wide XULRunner (e.g. Firefox), that often comes without JavaXPCOM. Thanks to that, project woudn't have to redistribute whole XULRunner, which saves application size and sometimes eliminates legal pains.

Comment 1

8 years ago
could you help me out a bit with this one?

Having JavaXPCOM as a separate DLL able to chat with XULRunner makes sense to me now.
I see that JavaXPCOM is located in mozilla-1.9.1/extensions/java/xpcom.
Is this all that's required to build it?
Do I understand correctly that all that needs to be done is to update the build scripts to produce DLL instead of object file?
For now, just do your hacking in a standard XULRunner build. We can change it to build as a standalone thing as a second step:

* Don't link it into libxul any more:
* Force it to be a shared library:
* Remove MOZILLA_INTERNAL_API/LIBXUL_LIBRARY. See for things that might need to change
* Link it using one of the XPCOM glue linking strategies (dependent glue is probably best at first):
Ever confirmed: true

Comment 3

8 years ago
Ok, I did first two
1. remove the whole ifdef MOZ_JAVAXPCOM from toolkit/library/ up to "endif #MOZ_JAVAXPCOM"
2. replace FORCE_STATIC_LIB =1 with FORCE_SHARED_LIB = 1 in java/xpcom/src/

And I'm going over 3rd step (remove internal API).

At this moment, when building I'm getting linking error. It's probably a good sign that I definitely should hurry up with 3rd step. correct?

Since I'm making changes only in extensions/java/xpcom - what's the easiest way to rebuild only this part of code tree?
For now I'm using make -f build at the top of mozilla source tree, but it's less than optimal.

Comment 4

8 years ago
Created attachment 407516 [details]
linking errors (78 unresolved externals)

Comment 5

8 years ago
(In reply to comment #3)
> For now I'm using make -f build at the top of mozilla source tree,
> but it's less than optimal.

"make libs" in <MOZ_OBJDIR>\extensions\java\xpcom does the trick :-)

now after changing from internal to frozen, I'm getting this:
c:\mozilla-source\mozilla-1.9.1\obj-i686-pc-mingw32\dist\include\xpcom\nsStringAPI.h(47) : fatal error C1189: #error :
nsStringAPI.h is only usable from non-MOZILLA_INTERNAL_API code!

Maybe there's an easier way to do this - e.g. first get a dll build with internal APIs, and then after solving linking problems, switch from internal to frozen.
just `make` in objdir/extensions/java/xpcom

The nsStringAPI.h #error is because the makefile still has LIBXUL_LIBRARY and/or MOZILLA_INTERNAL_API set.
Oh, and I don't think that switching to a DLL without removing the internal API is a very interesting intermediate step: it won't tell you much, and it would  only work in --disable-libxul builds anyway.

Comment 8

8 years ago
LIBXUL_LIBRARY and MOZILLA_INTERNAL_API is not set in extensions/java/xpcom, so it's probably something else setting it. Is it safe to just undef them, or shall I search for the root cause?

I'm using following mozconfig:
ac_add_options --enable-application=xulrunner
mk_add_options MOZ_CO_PROJECT=xulrunner

# build in separate obj directory

# debug
ac_add_options --disable-optimize
ac_add_options --enable-debug 

# remove ATL, see
ac_add_options --disable-xpconnect-idispatch
ac_add_options --disable-activex
ac_add_options --disable-activex-scripting
ac_add_options --disable-accessibility

ac_add_options --enable-javaxpcom
# export JAVA_HOME=/c/java/sun-java1.5.0_09/
#ac_add_options --with-java-bin-path=/c/java/sun-java-1.5.0_09/bin
I'd search for the root cause

Comment 10

8 years ago
Comment on attachment 407516 [details]
linking errors (78 unresolved externals)

This linking problems don't appear any more. I'm not sure why I was getting them earlier.
Attachment #407516 - Attachment is obsolete: true

Comment 11

8 years ago
Now javaxpcom.dll and javaxpcom.jar are building and I'm trying to initialize JavaXPCOM in Java.

I'm initializing JavaXPCOM via it's Mozilla class, then instantiating Mozilla browser via SWT API and trying to get JavaXPCOM reference from SWT Browser.
Following is Java code:

Mozilla.getInstance().initialize(new File(System.getProperty("org.eclipse.swt.browser.XULRunnerPath")));
try {
browser = new Browser(shell, SWT.MOZILLA);
} catch (SWTError e) {
System.out.println("Could not instantiate Browser: " + e.getMessage());
Object wb = browser.getWebBrowser();

And the result is:

Exception in thread "main" org.mozilla.xpcom.XPCOMException: Failed to register JavaXPCOM methods  (0x80460003)
	at org.mozilla.xpcom.internal.JavaXPCOMMethods.registerJavaXPCOMMethodsNative(Native Method)
	at org.mozilla.xpcom.internal.JavaXPCOMMethods.registerJavaXPCOMMethods(
	at org.mozilla.xpcom.internal.MozillaImpl.initialize(
	at org.mozilla.xpcom.Mozilla.initialize(
	at org.eclipse.swt.snippets.Snippet260.main(
Error loading C:\mozilla-source\mozilla-1.9.1\obj-without_javaxpcom\dist\bin\js3250.dll

Comment 12

8 years ago
Created attachment 410756 [details]

changes made so far.
Not sure what that last attachment is. What changes did you make to the Java source, and what linkage strategy are you using for javaxpcom.dll? In particular, you'll need to decide whether the Java code finds the XULRunner installation, or whether you load javaxpcom.dll and *that* finds the XULRunner installation, as that will determine whether you want to use dependent or standalone linkage.

I'm willing to bet that the error loading js3250.dll has something to do with library dependencies, which you might be able to track with dependency walker profiling mode.


4 years ago
Assignee: jhpedemonte → nobody


3 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.