JEPs proposed to target JDK 10 (2017/11/2) (original) (raw)

Roman Kennke roman at kennke.org
Mon Nov 6 10:35:12 UTC 2017

Hi Volker,

We started pushing JEP 304 related changes before the JEP has been targeted mostly because I did not know it. The JEP process is not clear about it. When we learned that having a JEP targeted is a pre-condition, we immediately moved it forward.

Also, all GC interface related changes so far have been kind-of prepraratory and the really big and important one (the barrier refactoring) will come after the JEP has been targeted.

The biggest issue is that the JEP is a sort of waterfall process, and it doesn't really align well with things like GC interface, which we are doing incrementally. In hindsight, it might have been more useful to not file a JEP to begin with. And I will certainly think twice before filing a JEP in the future.

Roman

Hi Mark,

DISCLAIMER: my comments are purely process related! In a previous post you wrote that the mainline will always be feature complete [1]. Looking at these JEPs, I wonder how we can ensure that? I know that the proposed JEPs have been extensively discussed and (at least partially) reviewed on the corresponding mailing list. Still, from looking at JBS alone, it seems impossible to find out if one of the proposed JEPs is feature complete and thus ready to be targeted for JDK 10. For example the JBS entry forJEP 304 mentions 15 issues it relates to. Five of these issues have already been fixed and integrated (which seems strange if the overall JEP hasn't even been targeted). I think if we take you "increase the release cadence" proposal seriously, such new JEPs should actually really be implemented in their own repositories (or branches) with their own builds and tests. Only then we could say (and prove) that a JEP is really ready for integration into the main line. Of course such an approach is completely unrealistic with our current setup. Another problem I see is that scope of a JEP may vary from a single webrev up to a douzen and more different issues but we currently treat them all in the same way. If there's a vague feeling that a JEP is 'mostly' implemented, we target it. We really need something like lightweight branches with their own builds and tests to effectively work in the proposed way. Finall, I want to stress once again, that I don't want to criticize the three proposed JEPs in any way. I fully support all of them and I think it is good to have them in JDK 10. I just wonder if we can meet the high goals you set when proposing the new release cadence with our current tools and infrastructure. Comments welcome ... Regards, Volker [1] http://openjdk.java.net/projects/jdk8/milestones#FeatureComplete <mark.reinhold at oracle.com> schrieb am Fr. 3. Nov. 2017 um 01:37:

The following JEPs have been placed into the "Proposed to Target" state by their owners after discussion and review:

304: Garbage-Collector Interface http://openjdk.java.net/jeps/304 307: Parallel Full GC for G1 http://openjdk.java.net/jeps/307 312: Thread-Local Handshakes http://openjdk.java.net/jeps/312 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Thursday, 9 November, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 10. - Mark

[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

More information about the jdk-dev mailing list