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