JEPs proposed to target JDK 10 (2017/11/2)
roman at kennke.org
Mon Nov 6 10:35:12 UTC 2017
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.
> Hi Mark,
> DISCLAIMER: my comments are purely process related!
> In a previous post you wrote that the mainline will always be feature
> complete .
> 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
> Comments welcome ...
>  http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
> <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
>> 307: Parallel Full GC for G1
>> 312: Thread-Local Handshakes
>> 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  I'll target these JEPs to JDK 10.
>> - Mark
>>  http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
More information about the jdk-dev