522443 - Move JavaXPCOM bridge from XULRunner core to separate extension

Status: RESOLVED WONTFIX

(Core Graveyard :: Java to XPCOM Bridge, enhancement, P3)

Description

[Jacek Pospychala]

As discussed at http://dev.eclipse.org/mhonarc/lists/atf-dev/msg00613.html
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

[Jacek Pospychala]

BDS,
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?

Comment 2

[Benjamin Smedberg]

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: http://mxr.mozilla.org/mozilla-central/source/toolkit/library/Makefile.in#95
* Force it to be a shared library: http://mxr.mozilla.org/mozilla-central/source/extensions/java/xpcom/src/Makefile.in#47
* Remove MOZILLA_INTERNAL_API/LIBXUL_LIBRARY. See https://developer.mozilla.org/en/Migrating_from_Internal_Linkage_to_Frozen_Linkage for things that might need to change
* Link it using one of the XPCOM glue linking strategies (dependent glue is probably best at first): https://developer.mozilla.org/en/XPCOM_Glue

Comment 3

[Jacek Pospychala]

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

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 client.mk build at the top of mozilla source tree, but it's less than optimal.

Comment 4

[Jacek Pospychala]

Attachment: linking errors (78 unresolved externals)

Comment 5

[Jacek Pospychala]

(In reply to comment #3)
> For now I'm using make -f client.mk 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.

Comment 6

[Benjamin Smedberg]

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.

Comment 7

[Benjamin Smedberg]

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

[Jacek Pospychala]

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
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@

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

# remove ATL, see https://developer.mozilla.org/en/atlbase.h
ac_add_options --disable-xpconnect-idispatch
ac_add_options --disable-activex
ac_add_options --disable-activex-scripting
ac_add_options --disable-accessibility

# JavaXPCOM
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

Comment 9

[Benjamin Smedberg]

I'd search for the root cause

Comment 10

[Jacek Pospychala]

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.

Comment 11

[Jacek Pospychala]

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());
display.dispose();
return;
}
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(JavaXPCOMMethods.java:60)
	at org.mozilla.xpcom.internal.MozillaImpl.initialize(MozillaImpl.java:48)
	at org.mozilla.xpcom.Mozilla.initialize(Mozilla.java:668)
	at org.eclipse.swt.snippets.Snippet260.main(Snippet260.java:41)
Error loading C:\mozilla-source\mozilla-1.9.1\obj-without_javaxpcom\dist\bin\js3250.dll

Comment 12

[Jacek Pospychala]

Attachment: patch

changes made so far.

Comment 13

[Benjamin Smedberg]

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.

Comment 14

[Mike Hommey [:glandium]]

JavaXPCOM was removed in bug 648593.