RFR: JDK-8072904: building jdk9 with jdk9 boot jdk can cause failure or incorrect results

[Dean Long]

Looks good to me too.

dl

On 2/11/2015 12:11 PM, David Holmes wrote:
> On 11/02/2015 9:35 PM, Erik Joelsson wrote:
>> Hello,
>>
>> New webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.02/
>>
>> On 2015-02-11 10:53, David Holmes wrote:
>>> Hi Erik,
>>>
>>> On 11/02/2015 7:23 PM, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> Please review this change to how javah is run on sa classes. Since the
>>>> sa classes in JDK 9 are now in a module instead of sa-jdi.jar, they 
>>>> are
>>>> (at least currently) available from the default bootclasspath. This
>>>> means that just setting -classpath to javah will not properly override
>>>> the versions of the classes found in the boot jdk with the versions
>>>> currently being built. The fix is to change -classpath with
>>>> -Xbootclasspath/p:.
>>>
>>> Seems like a temporary workaround. javah should have a way to indicate
>>> which class to process without assuming it comes from the JVM used to
>>> run javah. Also putting what was sa-jdi.jar on the bootclasspath seems
>>> somewhat misplaced - these aren't "boot" classes.
>>>
>> It was also pointed out to me that -Xbootclasspath is not future proof.
>> So instead I opted for a different solution, using the new javac flag -h
>> and the @Native annotation to automatically generate header files during
>> compilation.
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072904
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.01/
>>>
>>> Were are the changes for all the other (non-linux) platforms? :)
>>>
>> Right, I forgot about that. *sigh* This time I made the changes in all
>> the makefiles.
>
> :) Thanks Erik this looks good to me. I'd completely forgotten about 
> @Native - much cleaner solution!
>
> David
>
>> /Erik