RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10
jonathan.gibbons at oracle.com
Thu Mar 22 15:13:23 UTC 2018
There has always been a desire that most of JDK is free to use the
latest language and API features, meaning we must use the latest javac
to compile most most of JDK. That is where the "interim javac" comes in.
The interim JDK relies on javac and related tools being compilable by
the boot JDK. This imposes a restriction that the source code of those
tools must be conformant to the source version supported by the boot
JDK, meaning no use of any newer features. The javac team have always
lived with and accepted the N-1 restriction that this imposes. With a
more rapid cadence, it might be appropriate to revisit the N-1 rule. But
since a "last LTS" rule may imply N-5 or N-6 or so, that seems like too
I note that this is not just an issue for javac source code. If we were
currently on a "last LTS" rule, that implies JDK 8, which means the
build would still have to be bimodal and support both (boot)classpath
and modular builds. OK, that window is closing, but the general point is
that supporting older versions may affect more than just the javac team.
On 3/21/18 11:10 PM, Magnus Ihse Bursie wrote:
>> 21 mars 2018 kl. 23:20 skrev Jonathan Gibbons <jonathan.gibbons at oracle.com>:
>> Holding javac and related tools back to the latest LTS would indeed be somewhat onerous.
> Can we use the interim JDK build to get around this? Something like, if we can build a interim JDK with somewhat older tools, it can then be used to compile the javac proper?
> I can see that how with the increased release cadence, the assumptions behind the old N-1 scheme might not be valid anymore.
>> -- Jon
>>> On 03/21/2018 03:07 PM, Martin Buchholz wrote:
>>> Now that we are releasing jdks an order of magnitude faster than before, we
>>> should reconsider the N-1 boot jdk policy.
>>> The primary beneficiaries of this are compiler-dev, who might like to code
>>> using the very features they are implementing.
>>> But for users, being able to bootstrap with an ancient jdk is definitely
>>> A good compromise might be to be able to bootstrap with the most recent LTS
>>> release (jdk 8) but it might already be too late for that.
>>> On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson <erik.joelsson at oracle.com>
>>>> Now that JDK 10 has been officially released we can update the boot jdk
>>>> requirement for JDK 11. Cross posting this to jdk-dev to raise awareness of
>>>> this rather disruptive change.
>>>> This patch changes the requirement on boot jdk version in configure (and
>>>> updates the configuration that controls what JDK to use as boot in Oracle's
>>>> internal build system).
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083
More information about the jdk-dev