Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Magnus Ihse Bursie]

Looks good to me. 

/Magnus

> 30 apr. 2018 kl. 17:34 skrev Erik Joelsson :
> 
> Hello,
> 
> I'm re-starting this review with the original proposed patch. This changes 
> the required boot-JDK in configure from the set "9 10 or 11" to "10 or 11". 
> It also changes what Oracle uses in its automated build environment setup 
> from 9 GA to 10 GA.
> 
> I do this based on the proposal [1] to retain the historical N - 1 boot-JDK 
> policy, which has not met any objections yet.
> 
> http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
> 
> /Erik
> 
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001075.html
> 
>> On 2018-03-21 14:51, Erik Joelsson 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
> 

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Tim Bell]

Erik:

I'm re-starting this review with the original proposed patch. This
changes the required boot-JDK in configure from the set "9 10 or 11" to
"10 or 11". It also changes what Oracle uses in its automated build
environment setup from 9 GA to 10 GA.

I do this based on the proposal [1] to retain the historical N - 1
boot-JDK policy, which has not met any objections yet.

http://cr.openjdk.java.net/~erikj/8200083/webrev.01/

/Erik

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001075.html


Looks good.

Tim

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Erik Joelsson]

Hello,

I'm re-starting this review with the original proposed patch. This 
changes the required boot-JDK in configure from the set "9 10 or 11" to 
"10 or 11". It also changes what Oracle uses in its automated build 
environment setup from 9 GA to 10 GA.


I do this based on the proposal [1] to retain the historical N - 1 
boot-JDK policy, which has not met any objections yet.


http://cr.openjdk.java.net/~erikj/8200083/webrev.01/

/Erik

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001075.html

On 2018-03-21 14:51, Erik Joelsson 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

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Erik Joelsson]

Updating the bootjdk requirement for JDK 11 was controversial. Instead I 
propose that for now, we just update the bootjdk used for building JDK 
11 at Oracle to JDK 10 and let compatibility with JDK 9 be a best effort 
from the parts of the community that wants to support it.


Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.02/

/Erik


On 2018-03-21 14:51, Erik Joelsson 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

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Erik Joelsson]

Please note that it's not just language features, I would say it's more 
about library APIs that jdk.compiler uses. The most obvious such change 
in the past is the modules API. In JDK 9, we had to keep the 
jdk.compiler modules (with friends) compatible with both a pre modules 
and post modules environment. Being able to scrap all those extra 
workarounds (reflective access, duplicate implementations, filtered 
classes at compile time etc) already in 10 made development and 
maintenance of that source much simpler.


I agree that OpenJDK is mainly for users, but my view of users is mainly 
the people using OpenJDK, not the ones building it. Sure, it is an open 
source project and as such a user is free to download and build from 
source on their own. However, the vast majority is downloading prebuilt 
binaries. Given that, I see the main conflict in this case rather being 
between OpenJDK developers and the package maintainers/distributors who 
regularly have to build it.


I don't really think it's fair that the OpenJDK developers should have 
to pay a heavy development and maintenance tax just to make it a little 
bit more convenient to build the product from source.


/Erik


On 2018-03-23 19:13, John Paul Adrian Glaubitz wrote:

On 03/24/2018 01:07 AM, Magnus Ihse Bursie wrote:

But if javac developers are seriously hindered in their effort to enhance Java 
due to this, then maybe developer convenience is not as important.

But is using the latest Java features really so important for OpenJDK
development? I mean, do people seriously say "Oh, we have type inference
for variables now. We have to use it immediately, it's making the code so
much better and faster!!!" (sorry, couldn't resist the hyperbole).

I mean, in the end, OpenJDK is developed for users and not for the OpenJDK
developers sake to use Java, isn't it? So, I think the project should always
keep users and downstream interests in mind.

Adrian

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[dalibor topic]

On 24.03.2018 03:13, John Paul Adrian Glaubitz wrote:

But is using the latest Java features really so important for OpenJDK
development? 


Generally speaking, being able to use the latest features is important 
because they typically reduce cost of both development (short term) & 
maintenance (long term).


For a non-obvious example, having to support two ways of doing something 
because one way was deprecated and removed, but one is stuck with some 
old baseline where it still wasn't adds non-trivial cost to design, 
decision making, maintenance, etc.


cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[John Paul Adrian Glaubitz]

On 03/24/2018 01:07 AM, Magnus Ihse Bursie wrote:
> But if javac developers are seriously hindered in their effort to enhance 
> Java due to this, then maybe developer convenience is not as important.

But is using the latest Java features really so important for OpenJDK
development? I mean, do people seriously say "Oh, we have type inference
for variables now. We have to use it immediately, it's making the code so
much better and faster!!!" (sorry, couldn't resist the hyperbole).

I mean, in the end, OpenJDK is developed for users and not for the OpenJDK
developers sake to use Java, isn't it? So, I think the project should always
keep users and downstream interests in mind.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Martin Buchholz]

On Thu, Mar 22, 2018 at 8:13 AM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:

>
> 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.
>

Historically, major java releases came out about once every 3 years, which
aligns pretty well with a "last LTS" rule.

Non-LTS releases such as jdk9 see cascading lack of support and hence lack
of adoption - your OS vendor may be reluctant to ship such a jdk.

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[joe darcy]

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 
:


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 


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

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Magnus Ihse Bursie]

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 
:


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 


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

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Jonathan Gibbons]

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.


-- Jon


On 3/21/18 11:10 PM, Magnus Ihse Bursie wrote:

Jon,


21 mars 2018 kl. 23:20 skrev Jonathan Gibbons :

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 
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

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Erik Joelsson]

Hello,

On 2018-03-21 15:07, 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.


Not just, we have had numerous tedious workarounds in the build for 
supporting different bootjdk versions (for just N and N-1) already and 
by adding more versions to that list, that kind of logic will balloon 
greatly. Maintaining a build that supports many different environments 
is hard, so being able to limit any variable helps. In practice there 
will still be the one version of boot jdk used by the automated build 
farms at Oracle and other places, which means any other boot jdk version 
is bound to break at times (as we already see for bootjdk version N 
often enough). It adds a complexity to the test matrix of the build that 
I think few OpenJDK developers are interested in keeping up with (as in, 
your change worked fine in your environment, but broke when building 
with bootjdk N-2.).
But for users, being able to bootstrap with an ancient jdk is 
definitely convenient.


There are different classes of users here. OpenJDK developers who have 
to build OpenJDK all day long every day. OpenJDK binary distributors who 
set up automated build environments for producing binaries at regular 
intervals. OpenJDK users who download the source to build it once for 
their own system. These are the ones I can think of right now.


For the developer, downloading the latest released version of the 
product they are developing every 6 months can hardly be such a big 
hassle. Most I know create their own convenience scripts to wrap the 
build with the configure parameters they commonly use so can easily 
automate setting up builds for building various versions of JDK N.


For the binary distributor, again downloading the latest released 
version, or using the latest version you built yourself for the previous 
release can't be that hard. They are (hopefully) setting up automation 
and this is just part of it.


Left are the users, who just wants to download and build from source to 
use it. I agree that we should strive for making OpenJDK as easy as 
possible to build for such users. However, getting any recent version of 
OpenJDK is pretty easy. Since JDK 9 you can even get OpenJDK binaries 
directly from jdk.java.net for the common main platforms.


Other people on this thread complained about building on more esoteric 
platforms where they only had older JDKs available and general downloads 
aren't available. Yes, having to build each JDK in succession would then 
take time, but surely this is a one time cost if you just keep the 
binaries around for released versions of the JDK. Also, we try to 
maintain reasonable cross compiling support in the build system. I 
recommend leveraging that.
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.


Reintroducing support for bootjdk 8 when building JDK 11 will not 
happen. We removed all the ugly workarounds needed for using a pre 9 
bootjdk for 10 long ago.


Long term though, perhaps this idea would be reasonable given the 
limited life time of non LTS. The required bootjdk would essentially be 
EOL long long before the LTS JDK N is. On the other hand, that would 
still be true for any bootjdk N-1 compared to JDK N. So given that, I'm 
still against.


/Erik

On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson 
mailto: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

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Erik Joelsson]

On 2018-03-21 23:10, Magnus Ihse Bursie wrote:

Jon,


21 mars 2018 kl. 23:20 skrev Jonathan Gibbons :

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?

No, I can't see how that could work for simplifying anything here.

/Erik

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 
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

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Thomas Stüfe]

On Thu, Mar 22, 2018 at 7:37 AM, Ao Qi  wrote:

> 2018-03-22 6:41 GMT+08:00 John Paul Adrian Glaubitz
> :
> > On 03/22/2018 07:07 AM, Martin Buchholz wrote:
> >> But for users, being able to bootstrap with an ancient jdk is definitely
> >> convenient.
> >
> > Convenient is an understatement. Always enforcing the N-1 version to be
> > used can be quite painful for downstream distributions. Rust upstream
> > does the same thing and it becomes very frustrating when bootstrapping
> > the compiler.
> >
> > When, for example, an architecture has fallen back a couple of releases
> > of OpenJDK, I would have to go through the whole chain of 8->9->10->11
> > to get the latest OpenJDK. I know that cross-compiling is possible, but
> > it's not always the easiest option.
> >
>
> Indeed. I was trying to build OpenJDK 11 zero on MIPS. Because I only had
> OpenJDK 8 binary as boot JDK, I have to build OpenJDK 9 first.
> It is even more painful when I build OpenJDK 11 32 bits zero. Because I
> only
> have 32-bit OpenJDK 6 as boot JDK, I have to build 7, 8, 9 and then 11.
>
>
And the build is not blindingly fast with a zero VM as boot jdk :)


> > So, from a downstream perspective, allowing the oldest possible version
> > is always a desirable feature to have. I do understand it though when
> > OpenJDK 11 requires features from OpenJDK 10 which would rule out older
> > versions completely.
> >
> > Adrian
> >
> > --
> >  .''`.  John Paul Adrian Glaubitz
> > : :' :  Debian Developer - glaub...@debian.org
> > `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> >   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Ao Qi]

2018-03-22 6:41 GMT+08:00 John Paul Adrian Glaubitz
:
> On 03/22/2018 07:07 AM, Martin Buchholz wrote:
>> But for users, being able to bootstrap with an ancient jdk is definitely
>> convenient.
>
> Convenient is an understatement. Always enforcing the N-1 version to be
> used can be quite painful for downstream distributions. Rust upstream
> does the same thing and it becomes very frustrating when bootstrapping
> the compiler.
>
> When, for example, an architecture has fallen back a couple of releases
> of OpenJDK, I would have to go through the whole chain of 8->9->10->11
> to get the latest OpenJDK. I know that cross-compiling is possible, but
> it's not always the easiest option.
>

Indeed. I was trying to build OpenJDK 11 zero on MIPS. Because I only had
OpenJDK 8 binary as boot JDK, I have to build OpenJDK 9 first.
It is even more painful when I build OpenJDK 11 32 bits zero. Because I only
have 32-bit OpenJDK 6 as boot JDK, I have to build 7, 8, 9 and then 11.

> So, from a downstream perspective, allowing the oldest possible version
> is always a desirable feature to have. I do understand it though when
> OpenJDK 11 requires features from OpenJDK 10 which would rule out older
> versions completely.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Magnus Ihse Bursie]

Jon,

> 21 mars 2018 kl. 23:20 skrev Jonathan Gibbons :
> 
> 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 
>> 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
>>> 
>>> 
> 

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Thomas Stüfe]

For what it is worth, I very much agree with Marting and Adrian.

It would make matters easier for downstream consumers if we could at least
retain N-2 compatibility, if compatibility to LTS is too much of a hassle
for Oracle.

Best Regards, Thomas

On Wed, Mar 21, 2018 at 11:41 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 03/22/2018 07:07 AM, Martin Buchholz wrote:
> > But for users, being able to bootstrap with an ancient jdk is definitely
> > convenient.
>
> Convenient is an understatement. Always enforcing the N-1 version to be
> used can be quite painful for downstream distributions. Rust upstream
> does the same thing and it becomes very frustrating when bootstrapping
> the compiler.
>
> When, for example, an architecture has fallen back a couple of releases
> of OpenJDK, I would have to go through the whole chain of 8->9->10->11
> to get the latest OpenJDK. I know that cross-compiling is possible, but
> it's not always the easiest option.
>
> So, from a downstream perspective, allowing the oldest possible version
> is always a desirable feature to have. I do understand it though when
> OpenJDK 11 requires features from OpenJDK 10 which would rule out older
> versions completely.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[John Paul Adrian Glaubitz]

On 03/22/2018 07:07 AM, Martin Buchholz wrote:
> But for users, being able to bootstrap with an ancient jdk is definitely
> convenient.

Convenient is an understatement. Always enforcing the N-1 version to be
used can be quite painful for downstream distributions. Rust upstream
does the same thing and it becomes very frustrating when bootstrapping
the compiler.

When, for example, an architecture has fallen back a couple of releases
of OpenJDK, I would have to go through the whole chain of 8->9->10->11
to get the latest OpenJDK. I know that cross-compiling is possible, but
it's not always the easiest option.

So, from a downstream perspective, allowing the oldest possible version
is always a desirable feature to have. I do understand it though when
OpenJDK 11 requires features from OpenJDK 10 which would rule out older
versions completely.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Jonathan Gibbons]

Holding javac and related tools back to the latest LTS would indeed be 
somewhat onerous.


-- 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 
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

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Martin Buchholz]

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 
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
>
>