JDK 14 RFR of JDK-8224630: ElementScannerN, N > 9 should scan type parameters

[Joe Darcy]

Thanks; filed JDK-8235445: "Update boot-jdk.m4 to derive -source/-target 
from centralized location".

-Joe

On 12/5/2019 1:16 PM, Erik Joelsson wrote:
> Fine with me.
>
> /Erik
>
> On 2019-12-05 09:20, Joe Darcy wrote:
>> On 12/5/2019 9:06 AM, Erik Joelsson wrote:
>>> On 2019-12-04 19:29, Joe Darcy wrote:
>>>> Hello,
>>>>
>>>> First on the build front, the -source/-target used in the bootstrap 
>>>> build of langtools was stuck at 9; in the change I'm proposing to 
>>>> update it to 13, the minimum boot JDK:
>>>>
>>>> --- old/make/autoconf/boot-jdk.m4    2019-12-04 19:16:42.209000999 
>>>> -0800
>>>> +++ new/make/autoconf/boot-jdk.m4    2019-12-04 19:16:41.925000999 
>>>> -0800
>>>> @@ -345,7 +345,7 @@
>>>>
>>>>    # When compiling code to be executed by the Boot JDK, force 
>>>> compatibility with the
>>>>    # oldest supported bootjdk.
>>>> -  BOOT_JDK_SOURCETARGET="-source 9 -target 9"
>>>> +  BOOT_JDK_SOURCETARGET="-source 13 -target 13"
>>>>    AC_SUBST(BOOT_JDK_SOURCETARGET)
>>>>
>>> I had missed this configuration. Ideally I want all the versions 
>>> that need updating for each new release collected into the 
>>> version-numbers file, or even better, be derived from existing 
>>> numbers in there. Would it be ok to just derive this number from the 
>>> list of valid bootjdk versions?
>>
>>
>> I agree deriving the source/target values from a centralized version 
>> numbers location is preferable. I tracked down this file since I want 
>> to use "var" in this changeset, a Java 10 language feature, and got 
>> unexpected compilation errors.
>>
>> How about I push the current changes while a fuller build fix is 
>> worked on?
>>
>> -Joe
>>