JEP proposed to target JDK 12: 325: Switch Expressions (Preview)
roman at kennke.org
Tue Aug 28 22:19:40 UTC 2018
>>>> The following JEP is proposed to target JDK 12:
>>>> 325: Switch Expressions (Preview)
>>>> Feedback on this proposal is more than welcome, as are reasoned
>>>> objections. If no such objections are raised by 23:00 UTC on Friday,
>>>> 24 August, or if they’re raised and then satisfactorily answered, then
>>>> per the JEP 2.0 process proposal  I’ll target this JEP to JDK 12.
>>> The few objections raised here are not new, having already been raised
>>> and answered over on the amber-dev and amber-spec-experts lists. I’ve
>>> therefore targeted this JEP to JDK 12.
>> I am not following amber-dev nor amber-spec-experts. I found the
>> objections raised here very reasonable, in particular the objection to
>> not include a controversial feature as 'preview' which would then
>> manifest itself by people using it.
> That a few people don’t like a feature does not make it “controversial.”
> Aside from that, the very point of a preview language feature is to
> invite further feedback without completely committing to the current
> design, so of course people will use it (we hope!). They’re highly
> unlikely to use it in production, however, since preview features must
> be enabled explicitly, on the command line, at both compile time and
> run time . We’re thus free to revise this design, based on new
> information, before it’s etched into the stone of the language.
I was not fully aware of the implications of 'preview feature', that it
has to be enabled at compile&runtime and so on. Thanks for the pointer.
> Yet ...
>> I can't see that those objections
>> have been 'satisfactorily answered'. If they have been satisfactorily
>> answered on any of the amber-* mailing lists, maybe it would be worth to
>> repeat that here for those of use who don't follow those lists.
> This is a fair point. We can’t expect everyone to follow the progress
> of every JEP in complete detail, so if objections to targeting a JEP
> are raised then it’s reasonable to ask its owner to summarize previous
> relevant discussions and answers in response -- which, in this case,
> Brian has now done.
Yes, thank you!
>> an answer satisfactory if those who raised it agree and state here that
>> they're ok.
> Here I must disagree.
> If someone makes a suggestion during the development of a JEP, and that
> suggestion is reasonably rejected at that time, then if they really,
> really want to they can re-raise that suggestion as an objection when
> the JEP is proposed to target a specific release. To require that the
> objection be answered to their satisfaction, however, would open the
> door to design by consensus, which I doubt anyone actually wants.
Hmm, totally true.
> In such a case it is reasonable to ask if Committers who didn’t raise
> the objection are satisfied with the answers as summarized by the JEP’s
> owner. (Even then, however, complete consensus is not a criterion for
> So -- are you satisfied with Brian’s response?
I am. Thank you and Brian.
More information about the jdk-dev