123651 - Java code produced doesn't work with current Java to XPCOM Bridge

Status: RESOLVED WONTFIX

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

Description

[Marcus Fellinger]

Check out xpidl from the mozilla trunk.
Check out the Java to XPCOM bridge.
Build xpidl.
Build the Java to XPCOM bridge using the previously build xpidl version.

Result:
The build fails, because nsID is undefined.

Problem:
nsID has been removed from the Java to XPCOM Bridge last year, and replaced with
ID, CID and IID. There is a version of xpidl on the Blackwood branch, that does
generate the correct code. But this doesn't get build, because it has the same
executable name as the one from the trunk. So the version on the trunk is used,
which besides using nsID, has a few other bugs, which were fixed on the
Blackwood branch (Bug #71951, 74511, 74525, 67457, 74742, 94186, 94192).

Possible solutions:
1. Integrate the Java to XPCOM version into the trunk
2. Use a different executable name for the Java to XPCOM version

Comment 1

[Phil Schwartau]

Formally confirming bug for consideration; cc'ing jband -

Comment 2

[John Bandhauer]

A one-time merge to the trunk is not helpful if the code owner is not willing to
maintain it there.

I'd say the realistic options are:
0) ignore the problem
1) remove xpidl_java.c form the trunk build
2) reassign to the owner of the "Java to XPCOM Bridge" component and see if he
wants to do anything about the problem.

Comment 3

[Marcus Fellinger]

Attachment: Patch for xpcom/typelib/xpidl/xpidl_java.c

This patch will replace generate of nsID-code in xpidl_java.c with ID, IID or
CID, depending on which ID is required. Compare with
java/xpcom/java/xpidl/xpidl_java.c

Comment 4

[Marcus Fellinger]

I added a patch for xpcom/typelib/xpidl/xpidl_java.c. This patch replaces the
code that generates nsID with code that generates ID, IID or CID, depending on
the type of ID requested.

Comment 5

[Marcus Fellinger]

I think there should only be one version of xpidl_java.c. Either on the trunk,
or on the Java to XPCOM bridge. In both cases, some bugs were only fixed in one
of both versions, so these bugfixes would have to be integrated into a single
version.

If we put xpidl_java.c in the Java to XPCOM bridge, it should be renamed, to (a)
clearly indicate that is only for java, and (b) allow people to use both in the
same Makefile, one to generate C++, the other to generate java code.

Comment 6

[Marcus Fellinger]

Attachment: Updated patch

Updated the patch. It now puts out package and import specifications in the
java_prolog.

Comment 7

[Marcus Fellinger]

Attachment: Patch, 3rd version

This version of the patch generates a separate java-file for each interface,
escapes methods that clash with java keywords or Object methods with an _, and
converts PRTime to long.

We should get rid of all the %{C++ } declarations in idl-files that are to be
accesible from java. Converting PRTime this way is a hack. The right solution
would be not to use prtime.h, but to declare PRTime using the basic IDL types.

Comment 8

[Marcus Fellinger]

Attachment: Patch for xpidl, next round

This patch fixes the following problems:

1. Typedefs from #includes are converted to the underlying native types (Bug
#94192)
2. Identifiers that match java keywords or Object methods are escaped
3. Maps nsID->ID, nsIID->IID, nsCID->CID.
4. Map PRTime->long.

Comment 9

[Marcus Fellinger]

Attachment: Patch for xpidl, v5

Method names now start with a lowercase letter

Comment 10

[Marcus Fellinger]

Attachment: Patch vor xpcom/typelib/xpidl, v6

Fixed a memory leak in xpidl_java.c.

This patch fixes the following:

1. Maps ns[IC]ID to [IC]ID.
2. Adds package the necessary package and import specifications;
3. Generates a separate java file for each interface
4. Converts method-names to start with a lowercase letter
5. Adds an underscore (_) to method- and parameter names that collide with
reserved words.
6. Maps idl typedefs to their native types
7. Maps PRTime->long (that's defined in a %{C++ } section in nsroot.idl)

Could someone please review this patch and tell me what you think about it?

Comment 11

[Marcus Fellinger]

Attachment: Patch for xpcom/typelib/xpidl, v7

Fixed Segmentation fault

Comment 12

[Phil Schwartau]

Marcus: thank you for all your work on this!!!

As jband mentioned in Comment #2 above, this should be taken
up by the owner of the Java to XPCom Bridge component, so I am
reassigning it there for consideration -

Comment 13

[Marcus Fellinger]

Well Igor, what do you think about merging xpidl_java.c back into the trunk?

I am currently working on a fix for Bug #55384, but that would require first
fixing this one.

I intend to have Blackwood working with Mozilla 1.0 the day Mozilla 1.0 is released.

Comment 14

[Marcus Fellinger]

Igor, could you please review this patch?

Comment 15

[Marcus Fellinger]

CC'ing [e-mail] and [e-mail], as they are working on
blackwood and might be able to review the bug.

Comment 16

[Brad Neuberg]

Just posted a significant patch on bug 189098 addressing these issues.

Comment 17

[jhp (no longer active)]

Blackconnect no longer builds and hasn't been worked on since 2001.  -> WONTFIX