I tried both xpidl-versions. If you use the one from the mozilla trunk, you will get code that doesn't compile. As I said, mozillas version uses nsID, but nsID has been removed from Blackwood, and the java XPCOM version takes that into account. So if at all, the java version is the more usable one, and the one on the trunk has bitrotten.
I just filed a bug against xpidl for producing java-code that doesn't build with the current java-to-XPCOM bridge (Bug #123651). Marcus John Bandhauer wrote: > AFAICT the Java XPCOM folk decided long ago to not be involved in the > mozilla trunk. xpcom/typelib/xpidl/xpidl_java.c is slowly rotting. > > We're accepting patches. File a blackwood bug (Component: Java to XPCOM > Bridge). Perhaps someone will do the work. > > John. > > Marcus Fellinger wrote: > >> Currently, there are two versions of xpidl that accept the -m java >> parameter, and generate java code. One is in xpcom/typelib/xpidl, the >> other is in java/xpcom/java/xpidl. However, only the later will >> generate compilable java-code. >> >> If you use the xpidl from the xpcom-tree, it will produce .java-files >> that contain nsID symbols. However, nsID was removed from Blackwood >> some time ago, and replaced with IID, CID, and ID. The xpidl from the >> java-tree correctly uses these. >> >> If one first builds SeaMonkeyAll, and then Blackwood, the xpidl from >> the java-tree won't be build, because a newer version already exists >> from the SeaMonkey-build. So, the wrong xpidl-version is used, causing >> the build to brake. >> >> We should integrate the xpidl-for-java code into the main xpidl-code, >> or drop the java-support from the main xpidl-code, and give the two >> versions different names, so there won't be any build conflicts. >> >> What do you think about this? >> >> - Marcus >> >
