Hi Volker,
On 16/10/2013 1:29 AM, Volker Simonis wrote:
Hi Erik, Alan,
first of all I think this is a good change because it helps porters to
build a complete JDK even if the newly build rmic wouldn't run.
On the other hand I'm a little bit concerned if this change still
allows it to bootstrap with a non-Oracle based bootstrap JDK. I
remember that we had some problems with IBM J9 as bootstrap JDK
because they have different default implementations of idlj and rmic
(see
http://hg.openjdk.java.net/ppc-aix-port/jdk7u/raw-file/tip/README-ppc.html#_TOC_ANCHOR_4_)
Fortunately, the IBM J9 also contains the original Oracle idlj and
rmic versions and with the old build it was possible to use them by
specifying the two variables:
IDLJ='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar
com.sun.tools.corba.se.idl.toJavaPortable.Compile'
RMIC='$(ALT_BOOTDIR)/bin/java -cp $(ALT_BOOTDIR)/lib/tools.jar
sun.rmi.rmic.Main'
I'm not sure if this is still possible with the new build system.
By the way, the main problem why the IBM J9 idlj and rmic didn't work
out of the box were some command line options which were only
supported by the Oracle implementation. It would therefore be very
nice if you could completely remove such options from the build.
As I understand it the rmic command (neither boot nor built) is never
executed now, so as long as the boot JDK can compile and run the
OpenJDK's rmic classes there should not be any problems.
David
-----
And you can easily check this by trying the IBM J9 as bootstrap JDK on
Linux/x86_64.
Thank you and best regards,
Volker
On Tue, Oct 15, 2013 at 4:40 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
On 15/10/2013 15:30, Erik Joelsson wrote:
Currently the RMI stubs in the jdk are built with the newly built rmic
binary at the end of the build. This patch changes that and instead builds a
bootstrap version of the rmic classes, much like bootstrap javac in
langtools, which runs on the bootjdk, but generates classes for the new jdk.
The new solution is more friendly to cross compilation.
A few notes on the patch:
* In src/share/classes/sun/tools/tree/Node.java, I had to change a call to
a jdk8 only constructor in java.lang.InternalError.
* The packages included when compiling rmic were just picked by extending
for each missing class until the compilation succeeded. If someone knows of
a crucial package or class that needs to be included, please say so.
* I renamed a parameter to SetupJavaCompilation. I do not consider the
parameter a hack anymore, but a necessary option for this case.
* In RMICompilation, the dependency file is now a real touch file instead
of a virtual one. This was needed for proper dependencies in
GenerateClasses.gmk.
* All of corba is compiled twice since I have no idea which parts would
actually be needed. This doesn't add much build time since it can be run
effectively in parallel with the rest of the corba build.
* I put the compilation of bootstrap rmic in GenerateClasses.gmk directly
instead of Tools.gmk. This was to not add much compile time, since Tools.gmk
is included and therefore parsed a lot.
Bug: https://bugs.openjdk.java.net/browse/JDK-6604021
Webrev: http://cr.openjdk.java.net/~erikj/6604021/webrev.01/
/Erik
It's great to see a solution coming for this, it was always been troublesome
to run the newly built rmic.
So what are the implications of this? I assume it means that we need to be
careful in sun.rmi.rmic, sun.tools.{asm,java,javac,tree,util} and restrict
API usage to what is available in the boot JDK - is that right?
-Alan.
