On Thu, 2012-07-05 at 11:59 +0200, Volker Simonis wrote:
Hi Jonathan,
that's strange. We speciall set the 'rmic' compiler to
RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar sun.rmi.rmic.Main'
in order to use the original, Oracle version of the compiler which should understand this option.
I fear that this is not altogether sufficient to avoid using IBM's version of the rmic compiler for IIOP-related artifact generation. rmic is the command for producing both Java Remote Method Protocol (JRMP) and Internet Inter-ORB Protocol (IIOP) artifacts. (Associated with IIOP generation, it also can produce IDL code and a "Mangled Name Table"). Each of these types of generation is done by a separate "back-end" to rmic. The back-end implementation for each generator can be specified (usually by an SDK provider) using the properties file 'sun/rmi/rmic/resources/rmicext.properties' (and its associated locale-specific variants). (These properties settings are picked up by the common rmic front-end, using a call to ResourceBundle.getBundle().) These properties files (if they exist) tend to be held within a jar file, alongside the code for the backend implementations. In an IBM SDK, that code, as so that properties file, is held in lib/ibmorbtools.jar. (The IBM SDK's lib/tools.jar has a 'Class-Path:' entry in it, which chains onto ibmorbtools.jar). So, in all cases, the rmic command invocation calls sun.rmi.rmic.Main, but the settings in the rmicext.properties file controls what backend code gets used. (Note: This is different to the way the idlj command works, for example, where there is no common front-end). Hope this helps to explain why the current approach is not having the desired effect. Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU