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
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
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 r
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.o
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 en
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
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 peo
On Thu, Mar 22, 2018 at 8:13 AM, Jonathan Gibbons <
[email protected]> 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
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/201
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
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
t
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.
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 wi
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
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 f
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 use
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 Adria
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
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 th
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 j
20 matches
Mail list logo
