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

RESOLVED WONTFIX

Status

Core Graveyard
Java to XPCOM Bridge
RESOLVED WONTFIX
16 years ago
4 years ago

People

(Reporter: Marcus Fellinger, Assigned: Igor Kushnirskiy)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments)

(Reporter)

Description

16 years ago
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

16 years ago
Formally confirming bug for consideration; cc'ing jband -
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

16 years ago
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.
(Reporter)

Comment 3

16 years ago
Created attachment 68103 [details] [diff] [review]
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
(Reporter)

Comment 4

16 years ago
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.
Keywords: patch
(Reporter)

Comment 5

16 years ago
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.
(Reporter)

Comment 6

16 years ago
Created attachment 68193 [details] [diff] [review]
Updated patch

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

Comment 7

16 years ago
Created attachment 68221 [details] [diff] [review]
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.
(Reporter)

Comment 8

16 years ago
Created attachment 68447 [details] [diff] [review]
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.
(Reporter)

Updated

16 years ago
Blocks: 124606
(Reporter)

Comment 9

16 years ago
Created attachment 68746 [details] [diff] [review]
Patch for xpidl, v5

Method names now start with a lowercase letter
(Reporter)

Comment 10

16 years ago
Created attachment 68845 [details] [diff] [review]
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?
(Reporter)

Comment 11

16 years ago
Created attachment 69548 [details] [diff] [review]
Patch for xpcom/typelib/xpidl, v7

Fixed Segmentation fault
(Reporter)

Updated

16 years ago
Blocks: 56682

Comment 12

16 years ago
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 -
Assignee: dbradley → idk
Component: xpidl → Java to XPCOM Bridge
QA Contact: pschwartau → avm
(Reporter)

Comment 13

16 years ago
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.
(Reporter)

Comment 14

16 years ago
Igor, could you please review this patch?
(Reporter)

Updated

16 years ago
Blocks: 94192
(Reporter)

Comment 15

16 years ago
CC'ing ashuk@eng.sun.com and joe.chou@eng.sun.com, as they are working on
blackwood and might be able to review the bug.
(Reporter)

Updated

16 years ago
Depends on: 127917

Comment 16

15 years ago
Just posted a significant patch on bug 189098 addressing these issues.
Blackconnect no longer builds and hasn't been worked on since 2001.  -> WONTFIX
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.