Build error on Linux PPC64 platform
Hello Volker, I met following problem when trying to build on my Power 5 box, OS is RedHat Enterprise Linux 5, bootstrapping JDK is also IBMSDK 7. /root/ppc-aix-port/depends/sdk7/bin/java -cp /root/ppc-aix-port/depends/sdk7/lib/tools.jar sun.rmi.rmic.Main -classpath "/root/ppc-aix-port/output_ppc-aix-port_dbg/../output_ppc-aix-port_dbg-debug/classes" \ -d /root/ppc-aix-port/output_ppc-aix-port_dbg/../output_ppc-aix-port_dbg-debug/classes \ -iiop -v1.2 \ -standardPackage \ javax.management.remote.rmi.RMIConnectionImpl -standardPackage is an invalid option or argument. The "-standardPackage" option does not seem to be supported, but I found this command passed in your build log, have you got any other changes to make this pass? Many thanks! Jonathan
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. Could you try the following on the command line (with your JDK version): /sapmnt/depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/bin/java -showversion -cp /sapmnt/depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage -verbose javax.management.remote.rmi.RMIConnectionImpl java version "1.7.0" Java(TM) SE Runtime Environment (build pxp6470-20110827_01) IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20110810_88604 (JIT enabled, AOT enabled) J9VM - R26_Java726_GA_20110810_1208_B88592 JIT - r11_20110810_20466 GC - R26_Java726_GA_20110810_1208_B88592 J9CL - 20110810_88604) JCL - 20110809_01 based on Oracle 7b147 [loaded /net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/jre/lib/rt.jar(javax/management/remote/rmi/RMIConnectionImpl.class) in 134 ms] [loaded /net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/jre/lib/rt.jar(javax/management/remote/rmi/RMIConnection.class) in 60 ms] [loaded /net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/jre/lib/rt.jar(java/io/Closeable.class) in 0 ms] [loaded /net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/jre/lib/rt.jar(java/lang/AutoCloseable.class) in 0 ms] ... [wrote /tmp/rmic_output/javax/management/remote/rmi/RMIConnectionImpl_Stub.class] [done in 26763 ms] Perhaps you have another version of IBMSDK and/or tools.jar? By the way, while analysing your problem I just realized that our current solution to set RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar sun.rmi.rmic.Main' isn't perfect, because as you can see in the above output, not only 'sun.rmi.rmic.Main' is resolved from 'tools.jar' but also the class 'javax.management.remote.rmi.RMIConnectionImpl' for which we we want to create the RMI interfaces. But this class should be resolved from the newly build JDK instead. I first thought I'll have to fix it but on the other hand the problem will disappear once we can bootstrap with our VM. Regards, Volker On Thu, Jul 5, 2012 at 10:24 AM, Jonathan Lu <luchsh@linux.vnet.ibm.com> wrote:
Hello Volker,
I met following problem when trying to build on my Power 5 box, OS is RedHat Enterprise Linux 5, bootstrapping JDK is also IBMSDK 7.
/root/ppc-aix-port/depends/sdk7/bin/java -cp /root/ppc-aix-port/depends/sdk7/lib/tools.jar sun.rmi.rmic.Main -classpath "/root/ppc-aix-port/output_ppc-aix-port_dbg/../output_ppc-aix-port_dbg-debug/classes" \ -d /root/ppc-aix-port/output_ppc-aix-port_dbg/../output_ppc-aix-port_dbg-debug/classes \ -iiop -v1.2 \ -standardPackage \ javax.management.remote.rmi.RMIConnectionImpl -standardPackage is an invalid option or argument.
The "-standardPackage" option does not seem to be supported, but I found this command passed in your build log, have you got any other changes to make this pass?
Many thanks! Jonathan
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
Hi Neil, thanks again for the detailed explanation. But it's still strange, why the same 'rmic' invocation succeeds on my machine but not on Jonathan's. As posted I use the following IBM JDK: java version "1.7.0" Java(TM) SE Runtime Environment (build pxp6470-20110827_01) IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20110810_88604 (JIT enabled, AOT enabled) J9VM - R26_Java726_GA_20110810_1208_B88592 JIT - r11_20110810_20466 GC - R26_Java726_GA_20110810_1208_B88592 J9CL - 20110810_88604) JCL - 20110809_01 based on Oracle 7b147 I checked "rmicext.properties" from ibmorbtools.jar. It has the followng entries: generator.args=v1.1,vcompat,v1.2,iiop,idl,xprint,mnt generator.class.default=sun.rmi.rmic.RMIGenerator generator.class.v1.1=sun.rmi.rmic.RMIGenerator generator.class.vcompat=sun.rmi.rmic.RMIGenerator generator.class.v1.2=sun.rmi.rmic.RMIGenerator generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator generator.class.idl=com.ibm.tools.rmic.iiop.IDLGenerator generator.class.xprint=com.ibm.tools.rmic.iiop.PrintGenerator generator.class.mnt=com.ibm.tools.rmic.iiop.MangledNameTableGenerator So according to your explanation, Jonathan should get the same results for running "<ibm_jdk>/bin/java -cp <ibm_jdk>/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl" as I did. Or is there something else which can influence the choice of the generator class. As far as I can see, the only place in Oracle's JDK which parses the "-standardPackage" option is in sun.rmi.rmic.iiop.StubGenerator (http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/file/tip/src/share/class...) but according to your explanation, my IBM JDK should choose "generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator" in that case. However if I do: <ibm_jdk>/bin/java -showversion -verbose:class -cp <ibm_jdk>/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl 2>&1 | grep iiop.StubGenerator class load: sun.rmi.rmic.iiop.StubGenerator from: file:/net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/lib/tools.jar I can see that it uses sun.rmi.rmic.iiop.StubGenerator instead. So there must some other configuration magic (at least on my machine). @Jonathan: could you please try the above command to check which version of StubGenerator you get. Regards, Volker On Thu, Jul 5, 2012 at 2:43 PM, Neil Richards <neil.richards@ngmr.net> wrote:
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
Hello Volker, The command "<ibm_jdk>/bin/java -cp <ibm_jdk>/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl " still gives the same error: "-standardPackage is an invalid option or argument." I think the problem is I'm using the latest release of IBMJDK, which is 70 SR1 (http://www.ibm.com/developerworks/java/jdk/linux/download.html#java7). java version "1.7.0" Java(TM) SE Runtime Environment (build pxp6470sr1-20120330_01(SR1)) IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20120322_106209 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR1_20120322_1720_B106209 JIT - r11_20120322_22976 GC - R26_Java726_SR1_20120322_1720_B106209 J9CL - 20120322_106209) JCL - 20120322_01 based on Oracle 7u3-b05 When I use pxp6470-20110827_01 to run the build, it will pass. The rmicext.properties is almost the same between these two builds, except for some copyright/date differences. So shall we define a fixed level of bootstrapping JDK before HotSpot gets to work? Regards Jonathan On 07/05/2012 11:07 PM, Volker Simonis wrote:
Hi Neil,
thanks again for the detailed explanation. But it's still strange, why the same 'rmic' invocation succeeds on my machine but not on Jonathan's.
As posted I use the following IBM JDK:
java version "1.7.0" Java(TM) SE Runtime Environment (build pxp6470-20110827_01) IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20110810_88604 (JIT enabled, AOT enabled) J9VM - R26_Java726_GA_20110810_1208_B88592 JIT - r11_20110810_20466 GC - R26_Java726_GA_20110810_1208_B88592 J9CL - 20110810_88604) JCL - 20110809_01 based on Oracle 7b147
I checked "rmicext.properties" from ibmorbtools.jar. It has the followng entries:
generator.args=v1.1,vcompat,v1.2,iiop,idl,xprint,mnt
generator.class.default=sun.rmi.rmic.RMIGenerator
generator.class.v1.1=sun.rmi.rmic.RMIGenerator generator.class.vcompat=sun.rmi.rmic.RMIGenerator generator.class.v1.2=sun.rmi.rmic.RMIGenerator generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator generator.class.idl=com.ibm.tools.rmic.iiop.IDLGenerator generator.class.xprint=com.ibm.tools.rmic.iiop.PrintGenerator generator.class.mnt=com.ibm.tools.rmic.iiop.MangledNameTableGenerator
So according to your explanation, Jonathan should get the same results for running "<ibm_jdk>/bin/java -cp <ibm_jdk>/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl" as I did. Or is there something else which can influence the choice of the generator class.
As far as I can see, the only place in Oracle's JDK which parses the "-standardPackage" option is in sun.rmi.rmic.iiop.StubGenerator (http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/file/tip/src/share/class...) but according to your explanation, my IBM JDK should choose "generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator" in that case. However if I do:
<ibm_jdk>/bin/java -showversion -verbose:class -cp <ibm_jdk>/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl 2>&1 | grep iiop.StubGenerator class load: sun.rmi.rmic.iiop.StubGenerator from: file:/net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/lib/tools.jar
I can see that it uses sun.rmi.rmic.iiop.StubGenerator instead. So there must some other configuration magic (at least on my machine).
@Jonathan: could you please try the above command to check which version of StubGenerator you get.
Regards, Volker
On Thu, Jul 5, 2012 at 2:43 PM, Neil Richards<neil.richards@ngmr.net> wrote:
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
Hi all, I'm not sure why your seeing inconsistent results between a 6 and 7, or how you're getting to the Sun/Oracle/OpenJDK IIOP generator impl without eliminating the effects of the rmicext.properties settings. However, I've a (hopefully) simple approach that will ensure you're not using the IBM generator, which should work in all cases (in SDKs for 6 & 7, anyhow) ... Just rename lib/ibmorbtools.jar to be something else. As the tools.jar tries to chain onto a file of that name, and that file contains the rmicext.properties files with the IBM-impl settings, moving that file off to one side should consistently cause rmic invocations to use the OpenJDK rmic IIOP generator. Approaching things this way would also mean one would not need to use the RMIC setting. (NB: One still need to use the IDLJ setting to use the OpenJDK idlj implementation, especially as moving the ibmorbtools.jar file aside also eliminates the IBM idlj implementation from the classpath). Hope this helps. Regards, Neil On Fri, 2012-07-06 at 16:09 +0800, Jonathan Lu wrote:
Hello Volker,
The command
"<ibm_jdk>/bin/java -cp <ibm_jdk>/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl "
still gives the same error: "-standardPackage is an invalid option or argument."
I think the problem is I'm using the latest release of IBMJDK, which is 70 SR1 (http://www.ibm.com/developerworks/java/jdk/linux/download.html#java7).
java version "1.7.0" Java(TM) SE Runtime Environment (build pxp6470sr1-20120330_01(SR1)) IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20120322_106209 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR1_20120322_1720_B106209 JIT - r11_20120322_22976 GC - R26_Java726_SR1_20120322_1720_B106209 J9CL - 20120322_106209) JCL - 20120322_01 based on Oracle 7u3-b05
When I use pxp6470-20110827_01 to run the build, it will pass. The rmicext.properties is almost the same between these two builds, except for some copyright/date differences. So shall we define a fixed level of bootstrapping JDK before HotSpot gets to work?
Regards Jonathan
On 07/05/2012 11:07 PM, Volker Simonis wrote:
Hi Neil,
thanks again for the detailed explanation. But it's still strange, why the same 'rmic' invocation succeeds on my machine but not on Jonathan's.
As posted I use the following IBM JDK:
java version "1.7.0" Java(TM) SE Runtime Environment (build pxp6470-20110827_01) IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20110810_88604 (JIT enabled, AOT enabled) J9VM - R26_Java726_GA_20110810_1208_B88592 JIT - r11_20110810_20466 GC - R26_Java726_GA_20110810_1208_B88592 J9CL - 20110810_88604) JCL - 20110809_01 based on Oracle 7b147
I checked "rmicext.properties" from ibmorbtools.jar. It has the followng entries:
generator.args=v1.1,vcompat,v1.2,iiop,idl,xprint,mnt
generator.class.default=sun.rmi.rmic.RMIGenerator
generator.class.v1.1=sun.rmi.rmic.RMIGenerator generator.class.vcompat=sun.rmi.rmic.RMIGenerator generator.class.v1.2=sun.rmi.rmic.RMIGenerator generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator generator.class.idl=com.ibm.tools.rmic.iiop.IDLGenerator generator.class.xprint=com.ibm.tools.rmic.iiop.PrintGenerator generator.class.mnt=com.ibm.tools.rmic.iiop.MangledNameTableGenerator
So according to your explanation, Jonathan should get the same results for running "<ibm_jdk>/bin/java -cp <ibm_jdk>/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl" as I did. Or is there something else which can influence the choice of the generator class.
As far as I can see, the only place in Oracle's JDK which parses the "-standardPackage" option is in sun.rmi.rmic.iiop.StubGenerator (http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/file/tip/src/share/class...) but according to your explanation, my IBM JDK should choose "generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator" in that case. However if I do:
<ibm_jdk>/bin/java -showversion -verbose:class -cp <ibm_jdk>/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl 2>&1 | grep iiop.StubGenerator class load: sun.rmi.rmic.iiop.StubGenerator from: file:/net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/lib/tools.jar
I can see that it uses sun.rmi.rmic.iiop.StubGenerator instead. So there must some other configuration magic (at least on my machine).
@Jonathan: could you please try the above command to check which version of StubGenerator you get.
Regards, Volker
On Thu, Jul 5, 2012 at 2:43 PM, Neil Richards<neil.richards@ngmr.net> wrote:
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
-- 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
Hello Neil, I've tested this approach on my LinuxPPC box by moving <IBMJDK>/lib/ibmorbtools.jar away, it works. Thanks! Regards Jonathan On 07/06/2012 08:04 PM, Neil Richards wrote:
Hi all, I'm not sure why your seeing inconsistent results between a 6 and 7, or how you're getting to the Sun/Oracle/OpenJDK IIOP generator impl without eliminating the effects of the rmicext.properties settings.
However, I've a (hopefully) simple approach that will ensure you're not using the IBM generator, which should work in all cases (in SDKs for 6 & 7, anyhow) ...
Just rename lib/ibmorbtools.jar to be something else. As the tools.jar tries to chain onto a file of that name, and that file contains the rmicext.properties files with the IBM-impl settings, moving that file off to one side should consistently cause rmic invocations to use the OpenJDK rmic IIOP generator.
Approaching things this way would also mean one would not need to use the RMIC setting.
(NB: One still need to use the IDLJ setting to use the OpenJDK idlj implementation, especially as moving the ibmorbtools.jar file aside also eliminates the IBM idlj implementation from the classpath).
Hope this helps. Regards, Neil
On Fri, 2012-07-06 at 16:09 +0800, Jonathan Lu wrote:
Hello Volker,
The command
"<ibm_jdk>/bin/java -cp <ibm_jdk>/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl "
still gives the same error: "-standardPackage is an invalid option or argument."
I think the problem is I'm using the latest release of IBMJDK, which is 70 SR1 (http://www.ibm.com/developerworks/java/jdk/linux/download.html#java7).
java version "1.7.0" Java(TM) SE Runtime Environment (build pxp6470sr1-20120330_01(SR1)) IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20120322_106209 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR1_20120322_1720_B106209 JIT - r11_20120322_22976 GC - R26_Java726_SR1_20120322_1720_B106209 J9CL - 20120322_106209) JCL - 20120322_01 based on Oracle 7u3-b05
When I use pxp6470-20110827_01 to run the build, it will pass. The rmicext.properties is almost the same between these two builds, except for some copyright/date differences. So shall we define a fixed level of bootstrapping JDK before HotSpot gets to work?
Regards Jonathan
On 07/05/2012 11:07 PM, Volker Simonis wrote:
Hi Neil,
thanks again for the detailed explanation. But it's still strange, why the same 'rmic' invocation succeeds on my machine but not on Jonathan's.
As posted I use the following IBM JDK:
java version "1.7.0" Java(TM) SE Runtime Environment (build pxp6470-20110827_01) IBM J9 VM (build 2.6, JRE 1.7.0 Linux ppc64-64 20110810_88604 (JIT enabled, AOT enabled) J9VM - R26_Java726_GA_20110810_1208_B88592 JIT - r11_20110810_20466 GC - R26_Java726_GA_20110810_1208_B88592 J9CL - 20110810_88604) JCL - 20110809_01 based on Oracle 7b147
I checked "rmicext.properties" from ibmorbtools.jar. It has the followng entries:
generator.args=v1.1,vcompat,v1.2,iiop,idl,xprint,mnt
generator.class.default=sun.rmi.rmic.RMIGenerator
generator.class.v1.1=sun.rmi.rmic.RMIGenerator generator.class.vcompat=sun.rmi.rmic.RMIGenerator generator.class.v1.2=sun.rmi.rmic.RMIGenerator generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator generator.class.idl=com.ibm.tools.rmic.iiop.IDLGenerator generator.class.xprint=com.ibm.tools.rmic.iiop.PrintGenerator generator.class.mnt=com.ibm.tools.rmic.iiop.MangledNameTableGenerator
So according to your explanation, Jonathan should get the same results for running "<ibm_jdk>/bin/java -cp <ibm_jdk>/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl" as I did. Or is there something else which can influence the choice of the generator class.
As far as I can see, the only place in Oracle's JDK which parses the "-standardPackage" option is in sun.rmi.rmic.iiop.StubGenerator (http://hg.openjdk.java.net/ppc-aix-port/jdk7u/corba/file/tip/src/share/class...) but according to your explanation, my IBM JDK should choose "generator.class.iiop=com.ibm.tools.rmic.iiop.StubGenerator" in that case. However if I do:
<ibm_jdk>/bin/java -showversion -verbose:class -cp <ibm_jdk>/lib/tools.jar sun.rmi.rmic.Main -d /tmp/rmic_output/ -iiop -v1.2 -standardPackage javax.management.remote.rmi.RMIConnectionImpl 2>&1 | grep iiop.StubGenerator class load: sun.rmi.rmic.iiop.StubGenerator from: file:/net/sapmnt.depot/tools/gen/linuxppc64/licenseware/jse/1.7.0/lib/tools.jar
I can see that it uses sun.rmi.rmic.iiop.StubGenerator instead. So there must some other configuration magic (at least on my machine).
@Jonathan: could you please try the above command to check which version of StubGenerator you get.
Regards, Volker
On Thu, Jul 5, 2012 at 2:43 PM, Neil Richards<neil.richards@ngmr.net> wrote:
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
participants (3)
-
Jonathan Lu
-
Neil Richards
-
Volker Simonis