Closed Bug 327846 Opened 15 years ago Closed 15 years ago

Implements some of JavaIDL spec

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jhpedemonte, Assigned: jhpedemonte)

Details

(Keywords: fixed1.8.1)

Attachments

(1 file)

Someone recently pointed me to the JavaIDL spec, specifically this document: http://www.omg.org/docs/ptc/00-11-03.pdf.  I looked at this in the past, when I first started work on JavaXPCOM;  but I mostly just looked at the type mapping table (section 1.4 in the PDF).  Much of this document doesn't apply to us, since XPIDL isn't really IDL, but there are some things we can use.

First, there is the list of reserved names (section 1.2.1).  It's more exhaustive than the list in JavaXPCOM, particularly with regards to java.lang.Object methods.  I have a patch for this.

Second, how should we handle 'out' and 'inout' params.  JavaXPCOM currently uses arrays to allow these values to be modified in the called method (same goes for the old BlackConnect and SWT).  JavaIDL creates Holder classes to allow the value to be modified.  I'll post more on this in a bit.
Summary: Implements some JavaIDL → Implements some of JavaIDL spec
* Adds to Java keywords list.
* I thought I had changed the underscore for reserved words to be prepended, but I checked it in as appending.  This is now fixed.
* Although I handled keywords when generating the Java interfaces, I wasn't actually handling it at runtime.
* In Java interfaces, methods are automatically "public", and fields are automatically "public static final".  It is recommended not to include these qualifiers.
HANDLING OF 'OUT' & 'INOUT' PARAMS

JavaIDL creates several helper classes when parsing an IDL interface.  One of these is the Holder class, which is used for 'out' and 'inout' params.  JavaXPCOM uses arrays, based mostly on the desing of BlackConnect and SWT.

For a given <type>, the <type>Holder class looks something like this:
  public class <type>Holder {
    public <type> value;
    public <type>Holder() {}
    public <type>Holder(<type> initial) {
      value = initial;
    }
  }

Each of the basic types (i.e. byte, short, int, ...) has its own Holder class (in the org.omg.CORBA package).  JavaIDL also creates a Holder for each parsed interface.  For our purposes, creating a Holder class for each interface seems excessive.  Instead, we could have an "NSISupportsHolder" class that could be used for all XPCOM objects;  the only downside is that this would require casting.

The use of arrays for these param modes is pretty much a hack, so it would be more Java-like to use these Holder classes.  What do you guys think?  And what do you think of the "NSISupportsHolder" class?
I just noticed the org.omg.CORBA.ObjectHolder class.  So we don't necessarily need an NSISupportsHolder class, we can just use ObjectHolder.
Hmm, actually, using ObjectHolder or NSISupportsHolder isn't ideal, since it doesn't provide enough compile-time type checking.  This could lead to man ClassCastExceptions when dealing with the wrong types.
Attachment #212408 - Flags: review?(benjamin)
Comment on attachment 212408 [details] [diff] [review]
java keywords patch

It would be nice to use nsTHashtable<nsDepCharHashKey> instead of nsCStringHashSet.
Attachment #212408 - Flags: review?(benjamin) → review+
Checked in to trunk and 1.8 branch.  ->FIXED
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.