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?
/Erik
AC_SUBST(JAVAC_FLAGS)
This should get added to the list of files updated when the boot JDK
is revved.
On the javax.lang.model front, with the changes for records pushed
into JDK 14 there is now a ElementScanner14 class and I think it is
time to address
JDK-8224630: ElementScannerN, N > 9 should scan type parameters
http://cr.openjdk.java.net/~darcy/8224630.0/
CSR: https://bugs.openjdk.java.net/browse/JDK-8235371
As the bug title implies, the existing scanner classes don't touch
type parameters, which is arguably a bug. The scanners mostly touch
enclosed elements, but they do also touch method/constructor
parameters which are not considered to be enclosed elements.
In its current form, the webrev relies on the test previously added
for RoundEnvironment. However, I acknowledge it would be possible to
add tests for this particular change.
Thanks,
-Joe
