RFC: JEP JDK-8208089: Implement C++14 Language Features

David Holmes david.holmes at oracle.com
Mon Nov 19 12:56:54 UTC 2018


On 19/11/2018 5:04 pm, Kim Barrett wrote:
>> On Nov 19, 2018, at 1:31 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> On 16/11/2018 12:31 pm, Kim Barrett wrote:
>>>> On Oct 3, 2018, at 3:13 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>>
>>>> I've submitted a JEP for
>>>>
>>>> (1) enabling the use of C++14 Language Features when building the JDK,
>>>>
>>>> (2) define a process for deciding and documenting which new features
>>>> can be used or are forbidden in HotSpot code,
>>>>
>>>> (3) provide an initial list of permitted and forbidden new features.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8208089
>>> While there has been some discussion of this JEP here, so far only Mikael has officially
>>> reviewed or endorsed it.
>>
>> I added myself as a Reviewer.
> 
> Thanks.
> 
>>> Regarding the timing of this JEP, integration in time for JDK 12 seems unlikely.
>>
>> This doesn't strike me as a JEP that actually integrates anything. It wants to establish a process by which future C++ features are accepted for use with hotspot. That's just documentation on the OpenJDK wiki as far as I can see. The actual set of features and any "vote" on them can happen any time after the JEP is approved. Any actual use of those features can follow any time after that.
> 
> There is the integration of the build changes needed to enable the use of C++14.
> Presently we explicitly specify C++98 (actually, gnu++98) for gcc.
> We also presently permit the use of older versions of compilers that don’t support C++14
> (or even C++11) at all, or only partially.  Those need to be dropped.

Even so those changes don't need to be put in place until we actually 
need to start using a new feature. So I would still think we can 
finalize the JEP independently of the subsequent code changes.

>> I think it is important that all the port owners buy into this.
> 
> At least one port (aix_ppc) presently seems to have no way to support this change, because
> the compiler being used is seriously deficient and appears to be languishing.  (It doesn’t even
> support C++11, let alone C++14.)  I think the community could (and in my opinion, should)
> chose to move ahead despite that.  

Okay I've seen the mail on this - thanks.

Cheers,
David

> If a new and adequate compiler is expected “soon” then
> the community might choose to wait, or might proceed and let that port languish until the new
> compiler is available.  I think that’s all part of the discussion that should happen around the
> targeting of this JEP.  I hope this inadequate compiler on a relatively niche platform won’t be
> an indefinite blocker in this area.
> 
> 
> 


More information about the core-libs-dev mailing list