The default bug view has changed. See this FAQ.

Namespace/package for interfaces?

RESOLVED FIXED

Status

Core Graveyard
Java to XPCOM Bridge
RESOLVED FIXED
11 years ago
3 years ago

People

(Reporter: jhp (no longer active), Assigned: jhp (no longer active))

Tracking

({fixed1.8.1.2})

Trunk
fixed1.8.1.2

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

11 years ago
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 (http://www.mozilla.org/scriptable/typelib_file.html#InterfaceDirectoryEntry_namespace).  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"?
(Assignee)

Comment 1

11 years ago
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?
(Assignee)

Comment 2

11 years ago
Created attachment 243198 [details] [diff] [review]
use 'org.mozilla.interfaces'

Change package name to somewhat more generic 'org.mozilla.interfaces'.

Comment 3

11 years ago
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?
(Assignee)

Updated

11 years ago
Attachment #243198 - Flags: review?(benjamin)

Comment 4

11 years ago
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:    
   - GREVersionRange.java, 
   - IAppFileLocProvider.java    
   - IGRE.java    
   - IMozilla.java    
   - INIParser.java    
   - IXPCOM.java    
   - Mozilla.java    
   - ProfileLock.java
   - VersionComparator.java
   - XPCOMException.java    
   - XPCOMInitializationException.java
* 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 1.8.0.4 to 1.8.1.

 
(Assignee)

Comment 5

10 years ago
Created attachment 253519 [details] [diff] [review]
use 'org.mozilla.interfaces' (checked in)

Patch as checked in to trunk.
Attachment #243198 - Attachment is obsolete: true
Attachment #243198 - Flags: review?(benjamin)
(Assignee)

Comment 6

10 years ago
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Comment 7

10 years ago
Comment on attachment 253519 [details] [diff] [review]
use 'org.mozilla.interfaces' (checked in)

Not sure what the status of 1.8.1.2 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.
Attachment #253519 - Flags: approval1.8.1.2?
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?
(Assignee)

Comment 9

10 years ago
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 1.8.1.2 as their new baseline.
(Assignee)

Comment 10

10 years ago
Oh, also, XR is still considered a 'developer preview'.
Yeah, I don't care, especially since we haven't released a XR from 1.8.1 yet.
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
Attachment #253519 - Flags: approval1.8.1.2? → approval1.8.1.2+
(Assignee)

Comment 13

10 years ago
Checked in to MOZILLA_1_8_BRANCH.
Keywords: fixed1.8.1.2
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.