Build error on Linux PPC64 platform

[Neil Richards]

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/classes/sun/rmi/rmic/iiop/StubGenerator.java)
> > 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 at 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