Accelerating the JDK release cadence (original) (raw)
Ben Evans benjamin.john.evans at gmail.com
Tue Sep 12 17:54:46 UTC 2017
- Previous message: Accelerating the JDK release cadence
- Next message: Accelerating the JDK release cadence
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Sep 12, 2017 at 1:33 PM, dalibor topic <dalibor.topic at oracle.com> wrote:
On 12.09.2017 07:47, Ben Evans wrote:
On Tue, Sep 12, 2017 at 1:11 AM, <mark.reinhold at oracle.com> wrote:
In addition to divide-and-conquer, implementation features can be merged in an experimental mode at first (e.g., G1, AoT) and then, over time, be made non-experimental and even become the default, if appropriate, as they mature. On the subject of G1, doesn't the new release cycle reopen the case for delaying the cutover of G1 to default GC? The process in place for JDK 9 at this time is specified at http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-June/005884.html Quoting form the above mail: "The overall feature set has been frozen for some time now. No further enhancements, no matter how small and low-risk, will be approved after the Initial Release Candidate build."
This isn't an "enhancement". This is a suggestion to reconsider making default an implementation that seems to be unfit for purpose in a non-trivial %age of real world cases.
I repeat: Given the new release schedule, why is it so important that this high-profile potentially breaking change be forced through now? Isn't the whole point to allow implementation features to be merged, made non-experimental and become the default over time? Why the urgency to do it now, rather than in March or September 2018?
Ben
- Previous message: Accelerating the JDK release cadence
- Next message: Accelerating the JDK release cadence
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]