Last Comment Bug 330256 - Namespace/package for interfaces?
: Namespace/package for interfaces?
: fixed1.8.1.2
Product: Core Graveyard
Classification: Graveyard
Component: Java to XPCOM Bridge (show other bugs)
: Trunk
: All All
-- normal (vote)
: ---
Assigned To: jhp (no longer active)
Depends on:
  Show dependency treegraph
Reported: 2006-03-12 11:00 PST by jhp (no longer active)
Modified: 2014-09-24 05:43 PDT (History)
8 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

use 'org.mozilla.interfaces' (17.94 KB, patch)
2006-10-23 08:31 PDT, jhp (no longer active)
no flags Details | Diff | Splinter Review
Eclipse 3.2 Refactoring Script to change package name form "org.mozilla.xpcom" to "org.mozilla.interfaces" (696 bytes, application/xml)
2006-10-27 02:21 PDT, Micael Gallego
no flags Details
use 'org.mozilla.interfaces' (checked in) (14.18 KB, patch)
2007-01-31 13:28 PST, jhp (no longer active)
dveditz: approval1.8.1.2+
Details | Diff | Splinter Review

Description User image jhp (no longer active) 2006-03-12 11:00:37 PST
Currently, Mozilla interfaces (as defined in IDL files) are effectively in a flat namespace.  This works well enough for C/C++/JS, but not for other languages, such as Java (and C#?).

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.

However, that is not currently possible.  JavaXPCOM puts generated interfaces in the "org.mozilla.xpcom" namespace.

Ideally, every interface should be associated with some namespace.  On IRC, Shaver pointed out that the typelib format has support for namespaces (  But it is not used.  I don't know if xpidl knows how to handle it, but nsIInterfaceInfo does not expose a method for accessing the namespace of an interface.  What are the implications of changing nsIInterfaceInfo?  How would this affect JS (or other langs)?

If adding support for namespaces isn't feasible in the near future, then we should probably move Java interfaces to a more generic package, rather than the current "org.mozilla.xpcom".  Perhaps "org.mozilla.interfaces"?
Comment 1 User image jhp (no longer active) 2006-06-14 10:16:43 PDT
My idea for this was to define a "default" namespace for a given interface based on the MODULE defined in the Makefiles.  That is, the namespace would be "org.mozilla.{MODULE}", unless it is specifically overridden in the IDL file by using the "module [NAMESPACE] { }" notation.

The problem is, how do we handle forward declarations?  Right now, they are of the style "interface nsIFile;".  But xpidl has no way of knowing what namespace that interface belongs to.

The only fix for this I can think of is to change all of the forward declarations to include the appropriate namespace.  But this would be a massive change and would cause problems for others who build on top of Mozilla and define their own interfaces.

Any suggestions on how to handle this?
Comment 2 User image jhp (no longer active) 2006-10-23 08:31:19 PDT
Created attachment 243198 [details] [diff] [review]
use 'org.mozilla.interfaces'

Change package name to somewhat more generic 'org.mozilla.interfaces'.
Comment 3 User image Micael Gallego 2006-10-27 02:21:09 PDT
Created attachment 243762 [details]
Eclipse 3.2 Refactoring Script to change package name form "org.mozilla.xpcom" to "org.mozilla.interfaces"

With this Eclipse 3.2 refactoring script, you can apply it in your Java Project and it will change all references to interfaces from "org.mozilla.xpcom" to "org.mozilla.interfaces". The instructions are: 
- Create a MozillaInterfaces project in Eclipse
- Include source code of an old MozillaInterfaces-src.jar (with "org.mozilla.xpcom")
- Change your Java project to include MozillaInterfaces project instead MozillaInterfaces.jar
- Apply this refactoring scritp.
- Change your Java project to include a new MozillaInterfaces.jar (with "org.mozilla.interfaces") instead MozillaInterfaces Project

What do you think about this refactoring script?
Comment 4 User image Micael Gallego 2006-10-30 15:31:23 PST
If you follow this steps, your code with references to interfaces in "org.mozilla.xpcom" package will change to "org.mozilla.interfaces" package. 

* Create a Eclipse Java Project named MozillaInterfaces with source files in MozillaInterfaces-src.jar
* Remove the dependence to OLD MozillaInterfaces.jar (with "org.mozilla.xpcom" package) in your Java Project that uses xpcom.
* Add reference to the MozillaInterfaces project in your Java Project that uses xpcom.
* Create a package named "org.mozilla.interfaces".
* Move all xpcom interfaces from "org.mozilla.xpcom" to "org.mozilla.interfaces". The interfaces are all source files except:    
* Add the dependence to NEW MozillaInterfaces.jar (with "org.mozilla.interfaces" package for xpcom interfaces) in your Java Project that uses xpcom.
* Delete the MozillaInterfaces project.

When XULRunner 1.8.1 release appears I will make a screecast that shows migration from to 1.8.1.

Comment 5 User image jhp (no longer active) 2007-01-31 13:28:55 PST
Created attachment 253519 [details] [diff] [review]
use 'org.mozilla.interfaces' (checked in)

Patch as checked in to trunk.
Comment 6 User image jhp (no longer active) 2007-01-31 13:29:38 PST
Fixed on trunk.
Comment 7 User image jhp (no longer active) 2007-01-31 13:36:52 PST
Comment on attachment 253519 [details] [diff] [review]
use 'org.mozilla.interfaces' (checked in)

Not sure what the status of is, but it would be great to get this patch in, since we are planning to do an XR build off that branch.

This patch is XULRunner only.  The only changes to non-JavaXPCOM files (in config and xpidl) are only relevant to JavaXPCOM.
Comment 8 User image Daniel Veditz [:dveditz] 2007-01-31 14:42:04 PST
Is there any compatibility downside to changing mid-stream? Or has no one really build anything yet that would be affected?

bsmedberg, sound OK to you?
Comment 9 User image jhp (no longer active) 2007-01-31 14:44:45 PST
The main consumer of this is Eclipse's ATF project, which I also work on and am ready to update.  There are some other minor projects using it, but all this change will mean is that they change some of their imports.  Functionality stays the same.  They would just need to use XR as their new baseline.
Comment 10 User image jhp (no longer active) 2007-01-31 14:45:17 PST
Oh, also, XR is still considered a 'developer preview'.
Comment 11 User image Benjamin Smedberg [:bsmedberg] 2007-01-31 19:39:33 PST
Yeah, I don't care, especially since we haven't released a XR from 1.8.1 yet.
Comment 12 User image Daniel Veditz [:dveditz] 2007-02-01 14:09:31 PST
Comment on attachment 253519 [details] [diff] [review]
use 'org.mozilla.interfaces' (checked in)

given bsmedberg's OK, approved for 1.8 branch, a=dveditz for drivers
Comment 13 User image jhp (no longer active) 2007-02-01 14:31:48 PST
Checked in to MOZILLA_1_8_BRANCH.

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