RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

[Erik Joelsson]

On 2013-10-15 16:40, Alan Bateman 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?
>
That would be my conclusion at least.

/Erik