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

[Alexey Semenyuk]

jpackage is not and not planned to be available on Solaris. It is only 
on Windows, Linux and Mac. Is this a sufficient argument to bring in the 
patch as is and not rework it to make C++98 compliant?
According to the list of supported compilers [1] on platforms where 
jpackage is available they all support C++11 for several years already.


[1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms

- Alexey

On 3/3/2020 7:29 PM, Kim Barrett wrote:

On Mar 3, 2020, at 4:49 PM, Alexey Semenyuk  wrote:

How about C++11? I have a pending patch for jpackage that depends on C++11 
features that I hesitate to pull in jdk15.

The reasons for HotSpot (at least) not already being on C++14 (cost of
switching over the Solaris Studio based platform) also apply to C++11.
A big part of the work involves dealing with changes to the compilation
model, the runtime libraries, and the ABI, all of which are part of
Solaris Studio's transition from C++98 to C++11.

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

[Andrew Haley]

On 3/3/20 10:18 PM, John Paul Adrian Glaubitz wrote:
> On 3/3/20 10:26 AM, Andrew Haley wrote:
>> But one of the few things of which I am certain is that we must not
>> allow the needs of backporting to determine the future of Java. That's
>> the way of staying in the past.
>
> Unpopular opinion: It's the enterprise customers that mainly pay for the
> development of software, not the users of rolling release distributions.

I don't think that's an unpopular opinion at all! It's why most of us
who work on Java updates get paid.

Continuing to depend on C++98 is not good for us in the long term. It
means we're using an obsolete programming language, and that
inevitably carries its own risks, and we miss opportunities to do
things better.

> I know that maintaining old stuff is boring but that's where the money
> is made. Too many developers unfortunately seem to forget that.

Seriously now, who are you talking about? We spend a tremendous amount
of time and money maintaining old stuff.

>> As Patrick Head put it, “Some people tell me that Formula 1 would be
>> better if the drivers still used stick shifts, but that’s a bit like
>> saying, 'isn’t it a pity we don’t still walk around in clogs!'”
>
> Maintenance of stable software isn't done for nostalgic reasons, it's
> because enterprise customers need a reliable and stable platform to
> run their businesses on. A lot of businesses are still running on JDK-8
> for this reason.

Yes, that's why we do it.

> Running bleeding edge software might be an option for a single desktop
> user, but not in an enterprise environment with thousands of users
> or in a critical environment like the booking system of an airline.

Bear in mind that, if people hadn't pressed forward after JDK 7, there
wouldn't be a "legacy" JDK 8 to maintain.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Kim Barrett]

> On Mar 3, 2020, at 4:49 PM, Alexey Semenyuk  
> wrote:
> 
> How about C++11? I have a pending patch for jpackage that depends on C++11 
> features that I hesitate to pull in jdk15.

The reasons for HotSpot (at least) not already being on C++14 (cost of
switching over the Solaris Studio based platform) also apply to C++11.
A big part of the work involves dealing with changes to the compilation
model, the runtime libraries, and the ABI, all of which are part of
Solaris Studio's transition from C++98 to C++11.

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

[John Paul Adrian Glaubitz]

On 3/3/20 10:26 AM, Andrew Haley wrote:
> But one of the few things of which I am certain is that we must not
> allow the needs of backporting to determine the future of Java. That's
> the way of staying in the past.

Unpopular opinion: It's the enterprise customers that mainly pay for the
development of software, not the users of rolling release distributions.

I know that maintaining old stuff is boring but that's where the money
is made. Too many developers unfortunately seem to forget that.

> As Patrick Head put it, “Some people tell me that Formula 1 would be
> better if the drivers still used stick shifts, but that’s a bit like
> saying, 'isn’t it a pity we don’t still walk around in clogs!'”

Maintenance of stable software isn't done for nostalgic reasons, it's
because enterprise customers need a reliable and stable platform to
run their businesses on. A lot of businesses are still running on JDK-8
for this reason.

Running bleeding edge software might be an option for a single desktop
user, but not in an enterprise environment with thousands of users
or in a critical environment like the booking system of an airline.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Alexey Semenyuk]

How about C++11? I have a pending patch for jpackage that depends on 
C++11 features that I hesitate to pull in jdk15.


- Alexey

On 3/3/2020 5:22 AM, Volker Simonis wrote:

On Tue, Mar 3, 2020 at 10:26 AM Andrew Haley  wrote:

On 3/2/20 10:46 PM, Volker Simonis wrote:


As lead of the 8 and 11 update projects you probably know best, if this fix
will eventually be considered for backporting and choose your means wisely
:)

Yeah, I know. Srsly. :-)

But one of the few things of which I am certain is that we must not
allow the needs of backporting to determine the future of Java. That's
the way of staying in the past.

As Patrick Head put it, “Some people tell me that Formula 1 would be
better if the drivers still used stick shifts, but that’s a bit like
saying, 'isn’t it a pity we don’t still walk around in clogs!'”


Totally agree.


--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Volker Simonis]

On Tue, Mar 3, 2020 at 10:26 AM Andrew Haley  wrote:
>
> On 3/2/20 10:46 PM, Volker Simonis wrote:
>
> > As lead of the 8 and 11 update projects you probably know best, if this fix
> > will eventually be considered for backporting and choose your means wisely
> > :)
>
> Yeah, I know. Srsly. :-)
>
> But one of the few things of which I am certain is that we must not
> allow the needs of backporting to determine the future of Java. That's
> the way of staying in the past.
>
> As Patrick Head put it, “Some people tell me that Formula 1 would be
> better if the drivers still used stick shifts, but that’s a bit like
> saying, 'isn’t it a pity we don’t still walk around in clogs!'”
>

Totally agree.

> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. 
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>

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

[Andrew Haley]

On 3/2/20 10:46 PM, Volker Simonis wrote:

> As lead of the 8 and 11 update projects you probably know best, if this fix
> will eventually be considered for backporting and choose your means wisely
> :)

Yeah, I know. Srsly. :-)

But one of the few things of which I am certain is that we must not
allow the needs of backporting to determine the future of Java. That's
the way of staying in the past.

As Patrick Head put it, “Some people tell me that Formula 1 would be
better if the drivers still used stick shifts, but that’s a bit like
saying, 'isn’t it a pity we don’t still walk around in clogs!'”

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Andrew Haley]

On 3/2/20 9:51 PM, Kim Barrett wrote:
>> On Mar 2, 2020, at 7:00 AM, Andrew Haley  wrote:
>>
>> On 11/19/18 8:39 PM, Kim Barrett wrote:
>>> I don't see any benefit to making the first C++ code change that uses
>>> a new feature also incorporate the needed build system changes.
>>> Indeed, how does one develop that feature usage unless one has the
>>> build system changes already in hand?
>>>
>>> It seems to me that if the documentation says one can use some new
>>> language feature but the build system hasn't been updated to actually
>>> support doing so, then the documentation is wrong. And recall that
>>> this JEP includes making some new features available immediately.
>>> (That initial list might be modified as part of this JEP discussion.)
>>
>> What is the status of this? I thought we'd decide, but I still see
>>
>>   $1_CXXSTD_CXXFLAG="-std=gnu++98"
>>
>> in flags-cflags.m4
>>
>> I need std::make_unsigned in order to fix some undefined behaviour in
>> HotSpot. I could implement it myself in share/metaprogramming but if
>> we've agreed to allow C++14, can we please get it done now? Thx.
> 
> In light of JEP 362 "Deprecate the Solaris and SPARC Ports"
> https://bugs.openjdk.java.net/browse/JDK-8231554
> with the intended removal of Oracle Developer Studio (aka Solaris
> Studio) as a supported compiler sometime soon, we don't want to spend
> effort getting HotSpot to production quality on that platform with
> C++11/14 features enabled and in use.

OK. So, I guess this means that we're stuck with C++98 (!) for a while.

It's not too hard for me to write the support for make_unsigned and add
it to share/metaprogramming. I'll do that and see what people say.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Volker Simonis]

Andrew Haley  schrieb am Mo., 2. März 2020, 13:00:

> On 11/19/18 8:39 PM, Kim Barrett wrote:
> > I don't see any benefit to making the first C++ code change that uses
> > a new feature also incorporate the needed build system changes.
> > Indeed, how does one develop that feature usage unless one has the
> > build system changes already in hand?
> >
> > It seems to me that if the documentation says one can use some new
> > language feature but the build system hasn't been updated to actually
> > support doing so, then the documentation is wrong. And recall that
> > this JEP includes making some new features available immediately.
> > (That initial list might be modified as part of this JEP discussion.)
>
> What is the status of this? I thought we'd decide, but I still see
>
>$1_CXXSTD_CXXFLAG="-std=gnu++98"
>
> in flags-cflags.m4
>
> I need std::make_unsigned in order to fix some undefined behaviour in
> HotSpot. I could implement it myself in share/metaprogramming but if
> we've agreed to allow C++14, can we please get it done now? Thx.
>

As lead of the 8 and 11 update projects you probably know best, if this fix
will eventually be considered for backporting and choose your means wisely
:)


> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. 
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>

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

[Kim Barrett]

> On Mar 2, 2020, at 7:00 AM, Andrew Haley  wrote:
> 
> On 11/19/18 8:39 PM, Kim Barrett wrote:
>> I don't see any benefit to making the first C++ code change that uses
>> a new feature also incorporate the needed build system changes.
>> Indeed, how does one develop that feature usage unless one has the
>> build system changes already in hand?
>> 
>> It seems to me that if the documentation says one can use some new
>> language feature but the build system hasn't been updated to actually
>> support doing so, then the documentation is wrong. And recall that
>> this JEP includes making some new features available immediately.
>> (That initial list might be modified as part of this JEP discussion.)
> 
> What is the status of this? I thought we'd decide, but I still see
> 
>   $1_CXXSTD_CXXFLAG="-std=gnu++98"
> 
> in flags-cflags.m4
> 
> I need std::make_unsigned in order to fix some undefined behaviour in
> HotSpot. I could implement it myself in share/metaprogramming but if
> we've agreed to allow C++14, can we please get it done now? Thx.

In light of JEP 362 "Deprecate the Solaris and SPARC Ports"
https://bugs.openjdk.java.net/browse/JDK-8231554
with the intended removal of Oracle Developer Studio (aka Solaris
Studio) as a supported compiler sometime soon, we don't want to spend
effort getting HotSpot to production quality on that platform with
C++11/14 features enabled and in use.

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

[Andrew Haley]

On 11/19/18 8:39 PM, Kim Barrett wrote:
> I don't see any benefit to making the first C++ code change that uses
> a new feature also incorporate the needed build system changes.
> Indeed, how does one develop that feature usage unless one has the
> build system changes already in hand?
>
> It seems to me that if the documentation says one can use some new
> language feature but the build system hasn't been updated to actually
> support doing so, then the documentation is wrong. And recall that
> this JEP includes making some new features available immediately.
> (That initial list might be modified as part of this JEP discussion.)

What is the status of this? I thought we'd decide, but I still see

   $1_CXXSTD_CXXFLAG="-std=gnu++98"

in flags-cflags.m4

I need std::make_unsigned in order to fix some undefined behaviour in
HotSpot. I could implement it myself in share/metaprogramming but if
we've agreed to allow C++14, can we please get it done now? Thx.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[David Holmes]

On 20/11/2018 6:39 am, Kim Barrett wrote:

On Nov 19, 2018, at 7:56 AM, David Holmes  wrote:

On 19/11/2018 5:04 pm, Kim Barrett wrote:

On Nov 19, 2018, at 1:31 AM, David Holmes  wrote:

Hi Kim,

On 16/11/2018 12:31 pm, Kim Barrett wrote:

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 don't see any benefit to making the first C++ code change that uses
a new feature also incorporate the needed build system changes.
Indeed, how does one develop that feature usage unless one has the
build system changes already in hand?


Just trying to distinguish the JEP from the build changes that will 
enable what is agreed upon by the JEP versus the first use of such changes.


If you want it all tied together that's fine - you're right it likely 
won't make 12.


Cheers,
David
-



It seems to me that if the documentation says one can use some new
language feature but the build system hasn't been updated to actually
support doing so, then the documentation is wrong. And recall that
this JEP includes making some new features available immediately.
(That initial list might be modified as part of this JEP discussion.)

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

[Kim Barrett]

> On Nov 19, 2018, at 7:56 AM, David Holmes  wrote:
> 
> On 19/11/2018 5:04 pm, Kim Barrett wrote:
>>> On Nov 19, 2018, at 1:31 AM, David Holmes  wrote:
>>> 
>>> Hi Kim,
>>> 
>>> On 16/11/2018 12:31 pm, Kim Barrett wrote:
>>> 
>>> 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 don't see any benefit to making the first C++ code change that uses
a new feature also incorporate the needed build system changes.
Indeed, how does one develop that feature usage unless one has the
build system changes already in hand?

It seems to me that if the documentation says one can use some new
language feature but the build system hasn't been updated to actually
support doing so, then the documentation is wrong. And recall that
this JEP includes making some new features available immediately.
(That initial list might be modified as part of this JEP discussion.)

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

[David Holmes]

On 19/11/2018 5:04 pm, Kim Barrett wrote:

On Nov 19, 2018, at 1:31 AM, David Holmes  wrote:

Hi Kim,

On 16/11/2018 12:31 pm, Kim Barrett wrote:

On Oct 3, 2018, at 3:13 PM, Kim Barrett  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.

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

[Volker Simonis]

On Mon, Nov 19, 2018 at 9:00 AM Kim Barrett  wrote:
>
> > On Nov 19, 2018, at 2:04 AM, Kim Barrett  wrote:
> >
> >> On Nov 19, 2018, at 1:31 AM, David Holmes  wrote:
> >> 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.  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.
>
> Here’s what Volker said on the build-dev list, 2017-07-19, subject 
> “C++11/C++14 support in XLC ?”
>
> 
> - SAP is currently maintaining the AIX port in the OpenJDK and we're
> willing to do that in the future. But we're not IBM and we can not
> decide about the XLC feature list. If Oracle and the OpenJDK community
> finally decide to use C++11/14 features which are not available in XLC
> we have to live with that. We can either escalate the XLC deficiencies
> to IBM and suspend the port until the compiler gets fixed. Or we can
> switch the port to use the GCC tool chain with all the pros (bigger
> compatibility with Linux platforms) and cons (porting effort, testing,
> compatibility with other AIX software compiled with XLC, compiler
> support). While the GCC alternative sounds very appealing at a first
> glance it really isn't that perfect in reality, especially not for our
> commercial SAP JVM version of OpenJDK. One problem is the fact that
> there's no official support for GCC on AIX, the other is
> compatibility. Just think you had to replace Solaris Studio by GCC on
> Solaris :)
> 
>
> He had more to say on the general topic at the time.  I don’t know if anything
> has changed in the intervening nearly 1 1/2 years.
>

Not really. IBM is working on a new compiler which is in Beta now. But
neither have I tested it nor do I know exactly if it will have full
C++11/14 support.

As I wrote before, this is a chicken/egg problem which I can not solve
and I agree that it shouldn't be a blocker for OpenJDK. Therefore,
please go ahead and use whichever feature the OpenJDK community agrees
upon.

Regards,
Volker

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

[Kim Barrett]

> On Nov 19, 2018, at 2:04 AM, Kim Barrett  wrote:
> 
>> On Nov 19, 2018, at 1:31 AM, David Holmes  wrote:
>> 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.  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.

Here’s what Volker said on the build-dev list, 2017-07-19, subject “C++11/C++14 
support in XLC ?”


- SAP is currently maintaining the AIX port in the OpenJDK and we're
willing to do that in the future. But we're not IBM and we can not
decide about the XLC feature list. If Oracle and the OpenJDK community
finally decide to use C++11/14 features which are not available in XLC
we have to live with that. We can either escalate the XLC deficiencies
to IBM and suspend the port until the compiler gets fixed. Or we can
switch the port to use the GCC tool chain with all the pros (bigger
compatibility with Linux platforms) and cons (porting effort, testing,
compatibility with other AIX software compiled with XLC, compiler
support). While the GCC alternative sounds very appealing at a first
glance it really isn't that perfect in reality, especially not for our
commercial SAP JVM version of OpenJDK. One problem is the fact that
there's no official support for GCC on AIX, the other is
compatibility. Just think you had to replace Solaris Studio by GCC on
Solaris :)


He had more to say on the general topic at the time.  I don’t know if anything
has changed in the intervening nearly 1 1/2 years.

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

[Kim Barrett]

> On Nov 19, 2018, at 1:31 AM, David Holmes  wrote:
> 
> Hi Kim,
> 
> On 16/11/2018 12:31 pm, Kim Barrett wrote:
>>> On Oct 3, 2018, at 3:13 PM, Kim Barrett  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.

> 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.  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.

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

[David Holmes]

Hi Kim,

On 16/11/2018 12:31 pm, Kim Barrett wrote:

On Oct 3, 2018, at 3:13 PM, Kim Barrett  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.


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.


I think it is important that all the port owners buy into this.

Thanks,
David

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

[Kim Barrett]

> On Oct 3, 2018, at 3:13 PM, Kim Barrett  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.

Regarding the timing of this JEP, integration in time for JDK 12 seems unlikely.

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

[Aleksei Voitylov]

On 16/10/2018 02:25, Kim Barrett wrote:

On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov  
wrote:

Kim,

If you were suggesting to just proceed with the change without giving a 
sufficient lead time for the ports that were willing to upgrade to do so, that 
sounds very alarming.

What is "sufficient lead time"?  I'm not proposing an answer, just
suggesting that 3 months (approx time between JEP publication and JDK
12 fork) might be sufficient, and a worthy goal.  That's a decision
that ought to be made as part of the Targeting discussion for this
JEP.  Right now, it's not even a Candidate, since there's still work
to be done.
I'm fine with that, and you probably can assume to document this goal in 
the JEP if noone speaks up.



Meanwhile, our testing has finished and I'm now confident we will be able to 
switch ARM port over to 7.x in 12 time frame. There are several issues that we 
still need to diagnose, but this does not look like a blocker.

That's good news, though pretty much what I expected.

I'm more worried about Solaris.  Having a goal of JDK 12 may help move
things along.

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

[Kim Barrett]

> On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov  
> wrote:
> 
> Kim,
> 
> If you were suggesting to just proceed with the change without giving a 
> sufficient lead time for the ports that were willing to upgrade to do so, 
> that sounds very alarming.

What is "sufficient lead time"?  I'm not proposing an answer, just
suggesting that 3 months (approx time between JEP publication and JDK
12 fork) might be sufficient, and a worthy goal.  That's a decision
that ought to be made as part of the Targeting discussion for this
JEP.  Right now, it's not even a Candidate, since there's still work
to be done.

> Meanwhile, our testing has finished and I'm now confident we will be able to 
> switch ARM port over to 7.x in 12 time frame. There are several issues that 
> we still need to diagnose, but this does not look like a blocker.

That's good news, though pretty much what I expected.

I'm more worried about Solaris.  Having a goal of JDK 12 may help move
things along.

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

[Aleksei Voitylov]

Kim,

If you were suggesting to just proceed with the change without giving a 
sufficient lead time for the ports that were willing to upgrade to do 
so, that sounds very alarming.


Meanwhile, our testing has finished and I'm now confident we will be 
able to switch ARM port over to 7.x in 12 time frame. There are several 
issues that we still need to diagnose, but this does not look like a 
blocker.


-Aleksei


On 11/10/2018 22:23, Kim Barrett wrote:

On Oct 8, 2018, at 4:45 PM, Aleksei Voitylov  
wrote:

Kim,

Let's not underestimate the importance of continuous testing throughout the release 
cycle. Over the last year alternative platforms and configurations were broken 
accidentally not once (and I think the number is reaching 50 or something). Suggesting a 
platform to be "not supported for a release or two" may mean by the time the 
compiler is good the amount of issues to fix for a platform to regain quality may become 
a blocker for the next LTS. I really hope this is not the option Oracle is proposing.

My impression is that most of these were not toolchain issues per se.
Rather, they were broken or incomplete changes in platform-dependent
code that weren't tested on these "alternative" platforms before being
pushed.  Oracle has provided dev-submit so that non-Oracle folks can
do some minimal testing on all the platforms that Oracle supports.  I
know that I would sometimes like to have similarly "easy" testing for
various platforms not supported by Oracle.

I didn't suggest "no testing" if there is a compiler version that
supports the new language standards but has not yet been fully
product-qualified by the people who are using it.  I think gcc on arm
may be in that category.  But I think it would be very disappointing
if the complete lack of a usable version of some compiler were to
completely block us in this area.  (Unfortunately, such a lack appears
to be the situation for XLC compiler used for the AIX/ppc port.)  The
proposal is not very aggressive.


We both know what and how long it takes to do a thorough OpenJDK compiler 
upgrade. If the community were made aware of this earlier, I would have 
definitely started planning for a compiler upgrade for ARM port in JDK 11.

I'm understand that it takes time and effort to do a toolchain
upgrade. And turning on support for new language version without
changing the toolchain version isn't really all that different.

This proposal didn't suddenly appear out of nowhere.  There has been
wistful discussion about using new language features for a long time,
with an understanding that going anywhere with that was difficult
because of some popular toolchain deficiencies (notably MSVC++) and
the need to upgrade others.  There have been ongoing efforts in this
direction, e.g. various changes to support building with C++11/14
support enabled.  Oracle made toolchain upgrades in JDK 11, in part to
support the language standard change.  (Unfortunately, the relevant
toolchain upgrade JEP was labelled "Confidential", even though a lot
of the work was in the open, and some of it was explicitly about
dealing with differences arising from turning on C++11/14.)

I think JDK 12 for this JEP is reasonable goal at this stage.  Of
course, that goal might not be achieved, for a variety of reasons.
That's why it is not yet in the Targeted state and why there is a
formal process for moving to that state; there's still work to be
done, and we'll have to see how that work proceeds.


With that, I conditionally agree with the proposal provided cooperating ports 
are given sufficient lead time to upgrade. We started testing ARM with 7.3 and 
will report on success.

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

[Kim Barrett]

> On Oct 8, 2018, at 4:45 PM, Aleksei Voitylov  
> wrote:
> 
> Kim,
> 
> Let's not underestimate the importance of continuous testing throughout the 
> release cycle. Over the last year alternative platforms and configurations 
> were broken accidentally not once (and I think the number is reaching 50 or 
> something). Suggesting a platform to be "not supported for a release or two" 
> may mean by the time the compiler is good the amount of issues to fix for a 
> platform to regain quality may become a blocker for the next LTS. I really 
> hope this is not the option Oracle is proposing.

My impression is that most of these were not toolchain issues per se.
Rather, they were broken or incomplete changes in platform-dependent
code that weren't tested on these "alternative" platforms before being
pushed.  Oracle has provided dev-submit so that non-Oracle folks can
do some minimal testing on all the platforms that Oracle supports.  I
know that I would sometimes like to have similarly "easy" testing for
various platforms not supported by Oracle.

I didn't suggest "no testing" if there is a compiler version that
supports the new language standards but has not yet been fully
product-qualified by the people who are using it.  I think gcc on arm
may be in that category.  But I think it would be very disappointing
if the complete lack of a usable version of some compiler were to
completely block us in this area.  (Unfortunately, such a lack appears
to be the situation for XLC compiler used for the AIX/ppc port.)  The
proposal is not very aggressive.

> We both know what and how long it takes to do a thorough OpenJDK compiler 
> upgrade. If the community were made aware of this earlier, I would have 
> definitely started planning for a compiler upgrade for ARM port in JDK 11.

I'm understand that it takes time and effort to do a toolchain
upgrade. And turning on support for new language version without
changing the toolchain version isn't really all that different.

This proposal didn't suddenly appear out of nowhere.  There has been
wistful discussion about using new language features for a long time,
with an understanding that going anywhere with that was difficult
because of some popular toolchain deficiencies (notably MSVC++) and
the need to upgrade others.  There have been ongoing efforts in this
direction, e.g. various changes to support building with C++11/14
support enabled.  Oracle made toolchain upgrades in JDK 11, in part to
support the language standard change.  (Unfortunately, the relevant
toolchain upgrade JEP was labelled "Confidential", even though a lot
of the work was in the open, and some of it was explicitly about
dealing with differences arising from turning on C++11/14.)

I think JDK 12 for this JEP is reasonable goal at this stage.  Of
course, that goal might not be achieved, for a variety of reasons.
That's why it is not yet in the Targeted state and why there is a
formal process for moving to that state; there's still work to be
done, and we'll have to see how that work proceeds.

> With that, I conditionally agree with the proposal provided cooperating ports 
> are given sufficient lead time to upgrade. We started testing ARM with 7.3 
> and will report on success.

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

[Aleksei Voitylov]

Kim,

Let's not underestimate the importance of continuous testing throughout 
the release cycle. Over the last year alternative platforms and 
configurations were broken accidentally not once (and I think the number 
is reaching 50 or something). Suggesting a platform to be "not supported 
for a release or two" may mean by the time the compiler is good the 
amount of issues to fix for a platform to regain quality may become a 
blocker for the next LTS. I really hope this is not the option Oracle is 
proposing.


We both know what and how long it takes to do a thorough OpenJDK 
compiler upgrade. If the community were made aware of this earlier, I 
would have definitely started planning for a compiler upgrade for ARM 
port in JDK 11.


With that, I conditionally agree with the proposal provided cooperating 
ports are given sufficient lead time to upgrade. We started testing ARM 
with 7.3 and will report on success.


-Aleksei


On 08/10/2018 22:34, Kim Barrett wrote:

On Oct 6, 2018, at 11:07 AM, Aleksei Voitylov  
wrote:

Kim,

from an ARM port perspective, the stable GCC version is 4.9. The port compiles 
with stock GCC 7.3 but a lot of testing is required before moving to GCC 7.3. I 
agree on the overall direction and we'll commit resources to testing it 
further, but from an ARM port perspective it may happen JDK 12 is a little too 
optimistic.

GCC x86 is a lot more stable than for ARM32 and AARCH64.

It seems to me that JDK 11 being an LTS might provide an answer to this.

JDK 12 support for C++11/14 on arm32/aarch64 might be somewhat
"experimental" in that it might require a more recent compiler version
that hasn't received as much testing as was done for JDK 11.

Similarly, the AIX/ppc platform might not be supported after JDK 11
until an improved version of the relevant compiler becomes available.

I don't know if such an approach is acceptable to the community, nor
do I know how such a decision might be made.  But I think it would be
unfortunate if such issues blocked progress in this area.

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

[Thomas Stüfe]

Hi Kim,
On Mon, Oct 8, 2018 at 8:32 PM Kim Barrett  wrote:
>
> > On Oct 8, 2018, at 6:48 AM, Thomas Stüfe  wrote:
> >
> > Hi Kim,
> >
> > is this JEP only about C++14 features or shall we discuss older
> > features too? The reason I am asking is that I would like us to
> > officially endorse namespaces. Not inline namespaces, just plain old
> > namespaces.
>
> I would like to keep this JEP focused on C++11/14 usage.
>
> However, it presently describes a process for recording and updating
> HotSpot usage.  I think that process is pretty close to the de facto
> process, which is rarely used successfully because it's not written
> down anywhere.
>
> We could extract that part of the JEP out, formalize, discuss, agree,
> and record it.  Then you could propose a change and there would be a
> process for dealing with the proposal, rather than having it slide
> into oblivion because we don't know how to proceed.  And the JEP could
> be made a bit smaller because it could just refer to that process.
>

Yes, I would like that. It would be really good to have a process in
place to preserve and actually live a consensus about what features we
use.

We have the Hotspot Style Guide, but we let it become woefully
outdated in the face of new developments. I always smile when I read
the "Be sparing with templates." remark - that ship has sailed long
ago.

---

A small remark to the text of your JEP:

"As a rule of thumb, permitting features which simplify writing, and
especially reading, code should be encouraged."

I would like to add to that that simplifying build error analysis
should also be a goal. That directly influences programmer
productivity. We had some cases in the recent past where we spent a
lot of time scratching our heads over walls of template related
compiler errors.

(not sure how to reach this goal though, since this seems to be a
problem inherent in using C++ templates).

Best Regards, Thomas

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

[Kim Barrett]

> On Oct 6, 2018, at 11:07 AM, Aleksei Voitylov  
> wrote:
> 
> Kim,
> 
> from an ARM port perspective, the stable GCC version is 4.9. The port 
> compiles with stock GCC 7.3 but a lot of testing is required before moving to 
> GCC 7.3. I agree on the overall direction and we'll commit resources to 
> testing it further, but from an ARM port perspective it may happen JDK 12 is 
> a little too optimistic.
> 
> GCC x86 is a lot more stable than for ARM32 and AARCH64.

It seems to me that JDK 11 being an LTS might provide an answer to this.

JDK 12 support for C++11/14 on arm32/aarch64 might be somewhat
"experimental" in that it might require a more recent compiler version
that hasn't received as much testing as was done for JDK 11.

Similarly, the AIX/ppc platform might not be supported after JDK 11
until an improved version of the relevant compiler becomes available.

I don't know if such an approach is acceptable to the community, nor
do I know how such a decision might be made.  But I think it would be
unfortunate if such issues blocked progress in this area.

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

[Kim Barrett]

> On Oct 8, 2018, at 6:48 AM, Thomas Stüfe  wrote:
> 
> Hi Kim,
> 
> is this JEP only about C++14 features or shall we discuss older
> features too? The reason I am asking is that I would like us to
> officially endorse namespaces. Not inline namespaces, just plain old
> namespaces.

I would like to keep this JEP focused on C++11/14 usage.

However, it presently describes a process for recording and updating
HotSpot usage.  I think that process is pretty close to the de facto
process, which is rarely used successfully because it's not written
down anywhere.

We could extract that part of the JEP out, formalize, discuss, agree,
and record it.  Then you could propose a change and there would be a
process for dealing with the proposal, rather than having it slide
into oblivion because we don't know how to proceed.  And the JEP could
be made a bit smaller because it could just refer to that process.

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

[Volker Simonis]

On Mon, Oct 8, 2018 at 12:49 PM Thomas Stüfe  wrote:
>
> Hi Kim,
>
> is this JEP only about C++14 features or shall we discuss older
> features too? The reason I am asking is that I would like us to
> officially endorse namespaces. Not inline namespaces, just plain old
> namespaces.
>
> HotSpot makes very limited use of namespaces.
>
> Not really true, we already use them. E.g. in metaspace coding, I used
> them to keep the global name space clean and to keep internals
> internal. This was met with positive reviews, and it works on all
> toolchains, so compiler support should not be a problem. Using
> namespaces, we could get slowly replace the "AllStatic" classes, which
> are namespaces in all but name. In contrast to classes, namespaces can
> be spread over multiple files and compilation units, and allow for
> cleaner separation of internal and external coding.
>
> It also would allow us to get rid the middle-of-header-platform-inclusions:
>

That's overdue since a long time!
It would allow us to finally get correct code navigation in IDEs.

> For example, today we have:
>
> [os.hpp]
> class os: AllStatic {
> 
> (platform independent, outward facing os:: functions)
> #include "os_linux.hpp"
> >> (Inner class "Linux" with platform specific os functions)
> ...
> }
>
> Not only is the inclusion in the middle of a class terrifying, it also
> means the shared, outward facing os:: namespace contains class Linux
> and lots of platform specific internals.
>
> With namespaces one could:
>
> [os.hpp]
> namespace os {
> 
> (platform independent, outward facing os:: functions)
> 
> }
>
> [os_linux.hpp]
> namespace os {
> namespace Linux {
> (linux specific os functions)
> }
> }
>
> I think this is way cleaner, and keeps platform specifics from
> including files which only care for the shared os interface.
>
> --
>
> Note that I would prefer forbidding the "using" directive for callers
> of namespace functions, but rather force them to spell out the
> namespace:
>

As far as I saw, "using" directives are already on the "Exclude" list
in Kim's proposal.

> So, instead of this:
>
> using os;
> jlong m = available_memory();
>
> I would prefer this, which is our current practice with AllStatic childs:
>
> jlong m = os::available_memory();
>
> The latter form would keep the code grepable.
>
> Best Regards, Thomas
> On Wed, Oct 3, 2018 at 9:13 PM Kim Barrett  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
> >

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

[Thomas Stüfe]

Hi Kim,

is this JEP only about C++14 features or shall we discuss older
features too? The reason I am asking is that I would like us to
officially endorse namespaces. Not inline namespaces, just plain old
namespaces.

HotSpot makes very limited use of namespaces.

Not really true, we already use them. E.g. in metaspace coding, I used
them to keep the global name space clean and to keep internals
internal. This was met with positive reviews, and it works on all
toolchains, so compiler support should not be a problem. Using
namespaces, we could get slowly replace the "AllStatic" classes, which
are namespaces in all but name. In contrast to classes, namespaces can
be spread over multiple files and compilation units, and allow for
cleaner separation of internal and external coding.

It also would allow us to get rid the middle-of-header-platform-inclusions:

For example, today we have:

[os.hpp]
class os: AllStatic {

(platform independent, outward facing os:: functions)
#include "os_linux.hpp"
>> (Inner class "Linux" with platform specific os functions)
...
}

Not only is the inclusion in the middle of a class terrifying, it also
means the shared, outward facing os:: namespace contains class Linux
and lots of platform specific internals.

With namespaces one could:

[os.hpp]
namespace os {

(platform independent, outward facing os:: functions)

}

[os_linux.hpp]
namespace os {
namespace Linux {
(linux specific os functions)
}
}

I think this is way cleaner, and keeps platform specifics from
including files which only care for the shared os interface.

--

Note that I would prefer forbidding the "using" directive for callers
of namespace functions, but rather force them to spell out the
namespace:

So, instead of this:

using os;
jlong m = available_memory();

I would prefer this, which is our current practice with AllStatic childs:

jlong m = os::available_memory();

The latter form would keep the code grepable.

Best Regards, Thomas
On Wed, Oct 3, 2018 at 9:13 PM Kim Barrett  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
>

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

[Aleksei Voitylov]

Kim,

from an ARM port perspective, the stable GCC version is 4.9. The port 
compiles with stock GCC 7.3 but a lot of testing is required before 
moving to GCC 7.3. I agree on the overall direction and we'll commit 
resources to testing it further, but from an ARM port perspective it may 
happen JDK 12 is a little too optimistic.


GCC x86 is a lot more stable than for ARM32 and AARCH64.

-Aleksei

On 05/10/2018 00:09, Kim Barrett wrote:

On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov  
wrote:

Kim,

Thank you for posting this. It's an important step to make. I wanted to clarify 
a couple of points:

1. Since this is infrastructure JEP, is the version of JDK which will undergo 
such changes going to be some future version or does it apply to past versions 
as well? I'm concerned with how we can simplify security backports to 8u which 
(I currently assume) is not subject to this change.

Future version (perhaps as soon as JDK 12).  I don't think there is
any desire to backport this change.  And yes, introducing the use of
new language features will make backports even more interesting than
they already are.  That seems unavoidable if we're going to pursue
this direction.


2. Which versions of GCC do you tentatively consider at this point? Non-x86 
ports may have a problem upgrading to a specific version of GCC which the 
shared code will use and may need additional lead time to adjust.

I think our (ad hoc) testing has been limited to gcc 7.x. But looking
at the gcc language conformance tables and release notes, gcc 5.x
might be good enough, and gcc 6.x seems fairly likely sufficient. Of
course, older versions are more likely to have bugs in some of these
new features. Updating the minimum supported versions for gcc and
clang are noted as TBD in the JEP.

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

[Erik Helin]

On 10/4/18 2:31 PM, Magnus Ihse Bursie wrote:>> 4 okt. 2018 kl. 10:57 
skrev Martijn Verburg :

I like this initiative.  I'm wondering if some of these rules can be easily
codified or written into a jcheck style checker (ccheck?) so that Authors
can adhere to the conventions and not rely on a Human review to pick out
where that convention isn't met.


That's an interesting thought!

I googled around a bit, but could find no obvious candidate for doing such a 
check. In fact, parsing and analyzing C++ seems quite a hard problem, compared 
to many other languages. (Sad, but not really surprising.)

I found two possible routes to explore: cpplint [1], the official Google tool 
to verify that the Google C++ Style Guide [2] is followed, and Vera++ [3], a 
framework for creating scripts that can analyze and/or transform C++ code.


As usual there is of a third route, this one is "just a matter of 
programming" :)


The (probably) easiest way to enforce usage of only a subset of C++ is 
to write custom clang-tidy checks [0]. We could most likely write a 
couple of ASTMatchers [1] to watch out for features we do not want. It 
used to be very hard to use the clang tooling with HotSpot, but thanks 
to Robin Westberg's compile-commands patch [2] that just went in, this 
is no longer an issue.


Unfortunately I don't think requiring all contributors to install a 
custom version of clang-tidy with HotSpot checks is feasible, this is 
more something you would want to run in a CI setup.


Thanks,
Erik

[0]: https://clang.llvm.org/extra/clang-tidy/#writing-a-clang-tidy-check
[1]: http://clang.llvm.org/docs/LibASTMatchers.html
[2]: http://hg.openjdk.java.net/jdk/jdk/rev/804792ce736f

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

[Kim Barrett]

> On Oct 4, 2018, at 4:35 AM, Volker Simonis  wrote:
> 
> Hi Tim, Jeff,
> 
> Kim has assembled a quite detailed list of new C++ features intended for use 
> in HotSpot/OpenJDK (with links to the corresponding C++ standard)
> 
> https://bugs.openjdk.java.net/browse/JDK-8208089

Note that this list is intended as a starting point.  The JEP also describes a 
process for adding
to the list of permitted features, and I anticipate that process will be used.  
There are several
that I personally think would be good to add (perhaps with some limits or 
restrictions), but that
I think may involve more detailed discussion. And other folks may have their 
favorite must have
feature(s) that didn’t seem to me to be needed in this initial seed list.

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

[Kim Barrett]

> On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov  
> wrote:
> 
> Kim,
> 
> Thank you for posting this. It's an important step to make. I wanted to 
> clarify a couple of points:
> 
> 1. Since this is infrastructure JEP, is the version of JDK which will undergo 
> such changes going to be some future version or does it apply to past 
> versions as well? I'm concerned with how we can simplify security backports 
> to 8u which (I currently assume) is not subject to this change.

Future version (perhaps as soon as JDK 12).  I don't think there is
any desire to backport this change.  And yes, introducing the use of
new language features will make backports even more interesting than
they already are.  That seems unavoidable if we're going to pursue
this direction.

> 2. Which versions of GCC do you tentatively consider at this point? Non-x86 
> ports may have a problem upgrading to a specific version of GCC which the 
> shared code will use and may need additional lead time to adjust.

I think our (ad hoc) testing has been limited to gcc 7.x. But looking
at the gcc language conformance tables and release notes, gcc 5.x
might be good enough, and gcc 6.x seems fairly likely sufficient. Of
course, older versions are more likely to have bugs in some of these
new features. Updating the minimum supported versions for gcc and
clang are noted as TBD in the JEP.

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

[Aleksei Voitylov]

Kim,

Thank you for posting this. It's an important step to make. I wanted to 
clarify a couple of points:


1. Since this is infrastructure JEP, is the version of JDK which will 
undergo such changes going to be some future version or does it apply to 
past versions as well? I'm concerned with how we can simplify security 
backports to 8u which (I currently assume) is not subject to this change.


2. Which versions of GCC do you tentatively consider at this point? 
Non-x86 ports may have a problem upgrading to a specific version of GCC 
which the shared code will use and may need additional lead time to adjust.


Thanks,

-Aleksei


On 03/10/2018 22:13, Kim Barrett 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

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

[Magnus Ihse Bursie]

> 4 okt. 2018 kl. 10:57 skrev Martijn Verburg :
> 
> Hi Kim,
> 
> I like this initiative.  I'm wondering if some of these rules can be easily
> codified or written into a jcheck style checker (ccheck?) so that Authors
> can adhere to the conventions and not rely on a Human review to pick out
> where that convention isn't met.

That's an interesting thought!

I googled around a bit, but could find no obvious candidate for doing such a 
check. In fact, parsing and analyzing C++ seems quite a hard problem, compared 
to many other languages. (Sad, but not really surprising.)

I found two possible routes to explore: cpplint [1], the official Google tool 
to verify that the Google C++ Style Guide [2] is followed, and Vera++ [3], a 
framework for creating scripts that can analyze and/or transform C++ code.

Neither seem like an ideal solution. The Google tool is hard coded to support 
the Google rules. It's possible we can fork it and add our own, but it's not 
clear that this is even possible, much less so that it's a good way forward. 
Vera++, on the other hand, seems much more likely to be able to provide the 
tooling needed to write checks that enforce these rules. However, what we have 
is just a framework, and someone's got to write those rules (in TCL of all 
languages...). Then again, Vera++ is an old and quite popular tool, so its 
possible there is already a bunch of predefined rules that we can use as a 
starting point out there. (I didn't go that far in my analysis).

Apart from these two, there appear to be no popular, well-encompassing, open 
source C++ checker out there, that could possibly be verifying rules like 
these. :(

/Magnus

[1] https://github.com/google/styleguide/tree/gh-pages/cpplint
[2] https://google.github.io/styleguide/cppguide.html
[3] https://bitbucket.org/verateam/vera/wiki/Introduction

> 
> Cheers,
> Martijn
> 
> 
>> On Wed, 3 Oct 2018 at 20:13, Kim Barrett  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
>> 
>> 

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

[Martijn Verburg]

Hi Kim,

I like this initiative.  I'm wondering if some of these rules can be easily
codified or written into a jcheck style checker (ccheck?) so that Authors
can adhere to the conventions and not rely on a Human review to pick out
where that convention isn't met.

Cheers,
Martijn


On Wed, 3 Oct 2018 at 20:13, Kim Barrett  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
>
>

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

[Volker Simonis]

Hi Tim, Jeff,

Kim has assembled a quite detailed list of new C++ features intended for
use in HotSpot/OpenJDK (with links to the corresponding C++ standard)

https://bugs.openjdk.java.net/browse/JDK-8208089

Could you please provide a summary of which of these features are already
available since which version of xlC for AIX and potentially escalate the
implementation of the missing features within IBM’s xlC on AIX team.

Thank you and best regards,
Volker


Kim Barrett  schrieb am Mi. 3. Okt. 2018 um 22:13:

> 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
>
>

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

[mark . reinhold]

2018/10/3 12:13:15 -0700, kim.barr...@oracle.com:
> ...
> 
> https://bugs.openjdk.java.net/browse/JDK-8208089

Or, more readably: https://openjdk.java.net/jeps/8208089

- Mark

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

[Kim Barrett]

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