In addition, the APIs in the java.compiler module are bootstrapped along
with javac. Therefore, these APIs also have to abide by the same (N-k)
language feature policy as javac. If the bootstrap is older than
necessary, maintenance of these APIs would be overly constrained.
-Joe
On 3/23/2018 9:07 AM, Magnus Ihse Bursie wrote:
On 2018-03-22 16:13, Jonathan Gibbons wrote:
Magnus,
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 much.
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.
I would not propose a "last LTS" scheme, that seems far to infrequent
to be reasonable. But maybe "N-2" might be an acceptable compromise?
Just to be clear: As far as I understand, the balance to strike here
is between:
1) on one hand, giving developers more time to adjust their build
system to a newly available boot JDK.
2) on the other hand, allowing developers of javac access to new JDK
features.
In keeping with the N-1 rule, we are nominally doing the same thing,
but practically shifting things towards 2). That might still be the
right thing to do, but we will then need to acknowledge that this is
what we're doing.
Personally, I don't have any strong opinion either way. I agree with
Erik's idea to keep the test matrix minimal, but on the other hand,
there's a huge number of possible configurations to build OpenJDK on
which is not regularly tested by Oracle's build system, and that works
fine in most cases. If someone from the community needs it and it is
broken, they can submit a patch. I could live with stating that "N-1"
is officially supported and is guaranteed to work, but we will also
support "N-2" but you'll have to test it yourself and submit bug fixes
if it does not work.
But if javac developers are seriously hindered in their effort to
enhance Java due to this, then maybe developer convenience is not as
important.
/Magnus
-- Jon
On 3/21/18 11:10 PM, Magnus Ihse Bursie wrote:
Jon,
21 mars 2018 kl. 23:20 skrev Jonathan Gibbons
<jonathan.gibb...@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.
/Magnus
-- 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
convenient.
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.joels...@oracle.com>
wrote:
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
/Erik