-Xbootclasspath/p in the JDK build

[Mandy Chung]

Jonathan Gibbons wrote:
> Jonathan Gibbons wrote:
>> Aaaargh.
>>
>> The restrictions on bootclasspath are going to be an issue for 
>> building JDK, because -Xbootclasspath/p is used in various places in 
>> the build itself.  In particular, this will be a problem when we set 
>> SKIP_BOOT_CYCLE=false, because the first time round, the BOOT_DIR 
>> will be set to JDK 6, and -Xbootclasspath/p can be used; the second 
>> time round, the BOOTDIR will be the newly built JDK 7, and 
>> -Xbootclasspath/p might not be available.
>>

I would imagine that it will take some time (probably the next release) 
to transition from the -Xbootclasspath/p to -L <module-lib> for 
SKIP_BOOT_CYCLE.    I think option #4 is the best way for the time being.
 
>> Here are places where I know -Xbootclasspath/p is used in the build.
>>
>> 1. In the langtools build.xml file.
>>
>> The langtools build uses the BOOT_DIR javac to compile the new javac 
>> classes, then immediately uses those classes on the bootclasspath to 
>> recompile javac again, for use in the final product. This ensures 
>> that the javac in the final JDK is built with the latest sources (and 
>> not built with the BOOT_DIR javac.) Both the interim javac and the 
>> final javac are made available to the downstream parts of the build.
>>
>> 2. In the jdk Makefiles
>>
>> The interim javac referred to in the previous section is used to 
>> compile most of the classes in the other repositories. This is done 
>> by setting JAVAC_CMD to use the BOOT_DIR javac with the newly 
>> compiled javac classes on the bootclasspath.
>>
>>
>> There are 3 ways forward that I can see.
>>
>> 1. Support -Xbootclasspath/p:  This is arguably simpler than 
>> supporting plain -Xbootclasspath.
>>
>> 2. Leave javac, javadoc, javah to run in JVM legacy mode so that  
>> -Xbootclasspath/p: continues to work for these tools. The latest 
>> versions of these tools are all used in the build using BOOT_DIR and 
>> -Xbootclasspath.
>>
>> 3. Figure out rules to examine BOOT_DIR and decide if -Xbootclasspath 
>> is going to be available, or if we need to build a temporary module 
>> library for use with the -L option. Note this will require us to 
>> address the issues with -L that I raised in [1].
>>
>> In any case, if this has not already been implemented, I would 
>> recommend that the launcher should reject (give an error) options 
>> like -Xbootclasspath if it is not going to accept them. 
It's already implemented.
   http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000715.html

Mandy
>> Silently ignoring the options if they are not applicable is almost 
>> certainly the wrong thing to do.
>>
>> -- Jon
>>
>> [1] 
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000756.html
>>
>
>
> There is probably another way forward, which may be the best way for 
> the time being:
>
> 4. Examine BOOT_DIR to decide if modules are being used or not.  Then 
> use -Xmode:legacy if necessary as well as -Xbootclasspath/p: to run 
> the necessary tools in JVM legacy mode.
>
>
> -- Jon