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 <aleksei.voitylov at bell-sw.com> 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.
>