JDK-8310260 : Compile the JDK as C++17
  • Type: JEP
  • Component: not defined
  • Priority: P4
  • Status: Closed
  • Resolution: Rejected
  • Submitted: 2023-06-17
  • Updated: 2023-08-14
  • Resolved: 2023-08-01
Related Reports
Relates :  
JDK-8311380 - Prepare java.desktop for C++17
Relates :  
JDK-8208089 - JEP 347: Enable C++14 Language Features
Description
Summary
-------

Compile the JDK's C++ source code as the C++17 language.

Goals
-------

Since JDK 16, the language features used by C++ code in the JDK have been set to the C++14 language standard. The purpose of this JEP is to formally allow C++ source code changes within the JDK to use C++17 language features, and to give specific guidance about which of those features may be used in HotSpot code.

Non-Goals
-------

This JEP does not propose any usage or style changes for C++ code in the JDK that is outside of HotSpot. HotSpot's Style Guide has already been adapted for C++14 previously and should require only minimal changes.

Description
-------

### Changes to the Build System

Microsoft Visual C/C++ Compiler: Visual Studio 2019 is required for JDK 17 and above. (Earlier versions will be rejected by configure.) Change the existing -std:c++14 flag to -std:c++17 for C++.

Other supported compilers: Replace the -std=c++14 option -std=c++17.

The minimum supported version of gcc is 8

The minimum supported version of clang is 10

### Changes to C++ Usage in HotSpot code

The existing restrictions and best-practice recommendations for C++ usage in
HotSpot code are based on the C++14 language standard, and described in the
[HotSpot Style Guide](https://wiki.openjdk.java.net/display/HotSpot/StyleGuide).

Lists of new features for C++17, along with links to their
descriptions, can be found in the online documentation for some of the
compilers and libraries:

* [C++ Standards Support in GCC](https://gcc.gnu.org/projects/cxx-status.html)
* [C++ Support in Clang](https://clang.llvm.org/cxx_status.html)
* [Visual C++ Language Conformance](https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance)
* [libstdc++ Status](https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html)
* [libc++ Status](https://libcxx.llvm.org/cxx1y_status.html)

Risks and Assumptions
-------

Code that works with the current specification of C++14 may break when compiled as C++17, or may silently change behaviour without compilation errors due to differing semantics between the language versions.
Comments
Current aix-ppc port's latest supported compiler is C++17 capable: https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.1?topic=whats-new This compiler is supported since JDK21: https://wiki.openjdk.org/display/Build/Supported+Build+Platforms
14-08-2023
Oh well, guess this will have to be a regular enhancement instead then
02-08-2023
Little direct work is proposed here. In contrast to JEP 347, this JEP does not propose to include specific guidance on C++17 feature usage, which instead will be given in the HotSpot Style Guide, as it should be. Finally, this change will not be of broad interest to the Java developer community. A JEP for this change is therefore not justified. Rejecting.
01-08-2023
I made a couple of small edits. Aside from that, this seems to me ready to be moved to Candidate. It can't be targeted until supported platforms are using a C++17 capable compiler, of which the current aix-ppc port's compiler is not.
24-07-2023
Hi Kim, aside from the permitted features section that I've removed, is this good to go?
24-07-2023
Out of curiosity I've searched up C++23 support among compilers, and much to my surprise a lot of C++23 features already have somewhat widespread support: https://en.cppreference.com/w/cpp/compiler_support/23
04-07-2023
I've removed the list of permitted features as suggested before, since it's proven to be complicated to maintain
21-06-2023
"Dynamic memory allocation for over-aligned data" does not belong in this proposal as-is. It requires non-trivial implementation changes to actually have it and make it usable. That implementation and the associated style guide update should be their own RFE. I see no reason to mention gnu-specific attributes here. They are not part of C++17. I think the change to the "Attributes" section here should be explicit about what's being changed, rather than copying the existing style guide text with the change included in a way that a reader needs to make the comparison themselves to figure out that there is a difference and what that difference is. This still has the C++17 and C17 update entangled.
21-06-2023
Alright, in that case I'll leave this set as is, just the minimal features that we'll definitely want for C++17
20-06-2023
Why is the [[deprecated]] attribute explicitly called out? There's no suggested change from existing practice as described in the style guide. I don't think alignof or alignas are needed here. The C++17 feature you are "reaching for" here is "Dynamic memory allocation for over-aligned data": https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0035r4.html I think that's one of the features we're going to want to add to the "permit" list in short order. Then we can have alignof that doesn't lie for some types, and alignas that actually works for such types. So a proposal to change the style guide to permit that feature would need to include some edits to the existing alignof and alignas usage descriptions. Another feature I think we'll want to permit in short order is constexpr-if. But as I suggested above, I think we can reasonably let this proposal leave the feature set unchanged, and update the style guide in focused followups.
20-06-2023
I'll actually throw in some gcc attributes which I've confirmed to be equivalent to their current macros too, since they don't change anything major in behaviour
20-06-2023
I've changed the JEP to reflect some of the issues raised, I'll leave only the most relevant permitted features that HotSpot already allows in the existing permitted feature list to reflect how C++17 is related to them. More to come
20-06-2023
I'm focusing on the C++17 proposal, and not addressing C17 (which I think might be premature) with my comments. The permitted list here ought to be only new-in-C++17 features, not a copy-paste of JDK-8208089 with a couple of (C++14!) features added. It may also be that nothing should be added to the permitted list by this JEP, leaving that to future changes to the HotSpot Style Guide. JDK-8208089 included a list of permitted features that mostly seemed important reasons for moving the enabled standard forward. I'd also done some testing of them on all of the supported platforms. Anything added here should be similarly vetted. The "Changes to C++ Usage in HotSpot code" looks like a copy-paste from JDK-8208089. Is there anything different here? I don't think just copying that is needed, and is actually wrong. There was a change to the process for modifying the HotSpot Style guide after JDK-8208089. There have been other changes since then too. I think hewing to JDK-8208089 as a model would improve this, e.g. - Title should be "Enable C++17 Language Features", with a similar summary. - The description of the build system changes should mention minimum compiler versions. - The usage in HotSpot section should just reiterate that the HotSpot Style Guide describes the usage rules for HotSpot code. I don't think there is a CR for upgrading the aix-ppc port to use xlc17. There probably should be, and it should be a blocker for this.
20-06-2023
Kim, I've updated the JEP accordingly. Any feedback?
19-06-2023
I assumed that C17 was required alongside C++17, if that isn't the case I can leave that for another time, I'll split this up into JEP tasks as recommended soon
19-06-2023
I think this should be split between C and C++ updates. C++17 includes the C11 standard library by reference, but not later versions. That makes C17 not really relevant for C++ code in the JDK (so large chunks of the JDK, like HotSpot). Permitting the use of C++17 should also include specific guidance for HotSpot, as was done with JDK-8208089 and later modifications to the HotSpot Style Guide. Visual Studio compliance with recent versions of C is still rather behind (though improving, and making it better seems to be on Microsoft's roadmap, just not as urgently as C++ compliance), so it may not be appropriate to use many/most C17 features yet. The aix-ppc port currently uses a compiler (xlclang++ v16.x) that doesn't support C++17. There is ongoing work to update that port to use a newer version (Open XL C/C++ 17.1), but that appears to be a pretty substantial project (the migration documentation for that new version is hefty). This is another reason why using C17 may not be appropriate yet. I know of a number of C++17 features that we would really like to have. Are there similar C17 features? We only updated the build to C11 fairly recently (JDK-8292008).
18-06-2023