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

Erik Joelsson erik.joelsson at oracle.com
Thu Dec 5 21:16:33 UTC 2019


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
>



More information about the build-dev mailing list