RFR: 8314488: Compiling the JDK with C++17

[Johan Sjölen]

On Mon, 18 Aug 2025 04:07:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I'm hijacking the PR mechanism as a way to discuss new C++17 features that can
>> be more easily structured and captured than bare email. Once discussion
>> settles down I'll turn the results into HotSpot Style Guide changes. I don't
>> intend to integrate any version of this document to the OpenJDK repository.
>
> doc/cpp17-features.md line 128:
> 
>> 126: [n4147](http://wg21.link/n4147)
>> 127: [n4424](http://wg21.link/n4424)
>> 128: [p0386r2](http://wg21.link/p0386r2)
> 
> After looking at inline variables more carefully as part of writing it up for
> the style guide, I'm inclined to move inline variables to the undecided or
> forbidden category. They seem to be a solution to a problem I think we don't
> really have.
> 
> Basically, they let you provide the full definition for a non-local variable
> in a header file, rather than declaring it in the header and defining it in
> an associated .cpp file. The motivating use-case is a component or library
> that is header only, to simplify client use by avoiding build issues. But
> that's just not a thing we care about for HotSpot code.
> 
> So what WE get from an inline variable is having a complete declaration and
> definition in one place, rather than separating the declaration from the
> definition (so probably saving a little bit of code), at the cost of putting
> the initialization expression in the header (which might require pulling other
> stuff into the header), and maybe making the compiler work a little harder.
> 
> The benefit of that seems minimal at best.
> 
> The one part of it that seems slightly useful is that a constexpr variable is
> implicitly inline, so doesn't need a definition without an initializer in a
> .cpp file if the variable is ODR-used. Indeed, that's now treated as a
> duplicate defintion and deprecated usage. But we haven't had any warnings, so
> guessing we don't actually have any of those. We can take advantage of this
> for future usage.
> 
> Any other opinions?

It's a bit of ceremony to do the header + source file edits for static variables, but maybe it's one worth living with to not have to explain to people what an inline variable is. I think that they'll be accepting of `static constexpr` variables being defined inline, as there's no inline keyword involved and constexpr is already special anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2281504382