358350 - support for custom defined IDL interfaces

Status: RESOLVED WONTFIX

(Core Graveyard :: Java to XPCOM Bridge, defect)

Description

[Michal Ceresna]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061011 Fedora/1.5.0.7-7.fc6 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061011 Fedora/1.5.0.7-7.fc6 Firefox/1.5.0.7

I have the following usecase:

I've put some 3rd party extensions into my embedding application.
Now I would like to access the 3rd party components of this extensions
from javaxpcom.

The problem is that the required interfaces are of course not included in the MozillaInterfaces.jar file.

This patch allows the embedder to provide java interfaces for unknown IDL interfaces.


Reproducible: Always

Comment 1

[Michal Ceresna]

Attachment: interface provider (v1)

Comment 2

[Michal Ceresna]

Attachment: interface provider (v2)

added fix for java-implemented IDL interfaces where the IDL file has
methods/attributes with 3rd party interfaces

Comment 3

[jhp (no longer active)]

So if I understand this correctly, this patch is for handling interfaces that aren't in the "org.mozilla.xpcom" package and aren't represented by an IDL, correct?

I don't know if this will work fully.  It seems that you have only handled the Java side of things.  In order for Mozilla to know about an interface, it must be defined in an IDL and compiled into an XPT file.

If I remember correctly, you can specify new locations for the XPT files in the LocationProvider class passed to initEmbedding.  During startup, Mozilla will read your XPT files in addition to the standard ones shipped with XULRunner.  This way, all of Mozilla (including JavaXPCOM) will know about these new interfaces.

Then, on the Java side of things, you would compile the IDL files into Java interfaces and package them in a jar that your app links against, just like it links against MozillaInterfaces.jar.

Benjamin, is this summary correct?

Comment 4

[Benjamin Smedberg]

Yes, this sounds correct.

Comment 5

[Michal Ceresna]

(In reply to comment #3)
>So if I understand this correctly, this patch is for handling interfaces that
>aren't in the "org.mozilla.xpcom" package and aren't represented by an IDL,
>correct?

No, the java interfaces are not part of the org.mozilla.xpcom package, because the .xpt (.idl) files were simply not available at the time of xulrunner compilation.

Example1: I install a custom extension. This extension installs new .xpt files. I want to access these newly added components from java.

Example2: I develop a more complex application. Some of my XPCOM components are implemented in java, some in javascript. I want to make java <-> js calls between my components.

Comment 6

[Michal Ceresna]

(In reply to comment #5)
The hack which I used before to solve it was: generate the java interfaces with org.mozilla.xpcom package declaration and manually add them to the existing MozillaInterfaces.jar

The proposed patch allows to do it in a clean manner, that is keep the interfaces with my application logic. (e.g. in package org.myapp.businesslogic)

Comment 7

[Michal Ceresna]

Did some browsing of open javaxpcom bug, and this proposed patch can be exactly used to solve the problem described in bug 330256:

>For example, a company called Echo has a Java calendering product that they
>want to integrate with Firefox.  They may make their code available in the
>"com.echo.calendar" package (namespace).  If they have interfaces that they
>wish to expose to Firefox, they would want those under the same namespace.

Comment 8

[jhp (no longer active)]

It is an interesting solution, but I still have some reservations:

(In reply to comment #6)
> The hack which I used before to solve it was: generate the java interfaces with
> org.mozilla.xpcom package declaration and manually add them to the existing
> MozillaInterfaces.jar

(1) You don't necessarily need this patch or this hack.  Just compile the Java interfaces using xpidl (which you would have to do for this patch, also), and package them in their own jar.  Then just include this jar in your path, just like you include MozillaInterfaces.jar.

(2) I don't like the idea of interfaces being in a package other than "org.mozilla.xpcom" (or "org.mozilla.interfaces", as specified in another bug).  Allowing a developer to have Mozilla interfaces in another package would give the impression that there is namespace protection.  But all of the Mozilla interfaces are still in a flat namespace, which could result in name conflicts.

Comment 9

[Michal Ceresna]

>(1) You don't necessarily need this patch or this hack.  Just compile the Java
>interfaces using xpidl (which you would have to do for this patch, also), and
>package them in their own jar.  Then just include this jar in your path, just
>like you include MozillaInterfaces.jar.

Main motivation is to keep the java interfaces with the application
logic code, so that I can build self-containing modules.

My application consists of many components. Some are written in cpp, 
some in js, and most of the are writen in java with the following
logical structure:

org.xyz.extraction.xpath.nsIXPathExtractor //public component interface
org.xyz.extraction.xpath.internal.*        //implementation classes

>(2) I don't like the idea of interfaces being in a package other than
>"org.mozilla.xpcom" (or "org.mozilla.interfaces", as specified in another bug).
> Allowing a developer to have Mozilla interfaces in another package would give
>the impression that there is namespace protection.  But all of the Mozilla
>interfaces are still in a flat namespace, which could result in name conflicts.

the method getInterface(String idlName) in IInterfaceProvider receives
as a parameter only the name of idl type, that is "nsIDOMNode" instead of "org.mozilla.xpcom.nsIDOMNode".
Because there is no package name, I do not understand why it should 
cause confusion.

Comment 10

[Mike Hommey [:glandium]]

JavaXPCOM was removed in bug 648593.