Last Comment Bug 522443 - Move JavaXPCOM bridge from XULRunner core to separate extension
: Move JavaXPCOM bridge from XULRunner core to separate extension
Status: NEW
:
Product: Core Graveyard
Classification: Graveyard
Component: Java to XPCOM Bridge (show other bugs)
: unspecified
: ARM All
: P3 enhancement (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-15 02:15 PDT by Jacek Pospychala
Modified: 2014-09-24 05:43 PDT (History)
2 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
linking errors (78 unresolved externals) (30.16 KB, text/plain)
2009-10-21 06:09 PDT, Jacek Pospychala
no flags Details
patch (1.85 KB, text/plain)
2009-11-06 03:22 PST, Jacek Pospychala
no flags Details

Description Jacek Pospychala 2009-10-15 02:15:35 PDT
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 2009-10-15 02:30:31 PDT
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 [:bsmedberg] 2009-10-16 14:03:07 PDT
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 2009-10-21 06:08:18 PDT
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 2009-10-21 06:09:24 PDT
Created attachment 407516 [details]
linking errors (78 unresolved externals)
Comment 5 Jacek Pospychala 2009-10-21 07:17:59 PDT
(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 [:bsmedberg] 2009-10-21 08:02:04 PDT
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 [:bsmedberg] 2009-10-21 08:02:50 PDT
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 2009-10-21 08:10:40 PDT
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 [:bsmedberg] 2009-10-21 08:16:24 PDT
I'd search for the root cause
Comment 10 Jacek Pospychala 2009-11-06 02:58:32 PST
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 2009-11-06 03:02:58 PST
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 2009-11-06 03:22:36 PST
Created attachment 410756 [details]
patch

changes made so far.
Comment 13 Benjamin Smedberg [:bsmedberg] 2009-11-06 10:27:16 PST
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.

Note You need to log in before you can comment on or make changes to this bug.