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

Aleksei Voitylov aleksei.voitylov at bell-sw.com
Mon Oct 8 20:45:07 UTC 2018


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 

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.


On 08/10/2018 22:34, Kim Barrett wrote:
>> On Oct 6, 2018, at 11:07 AM, Aleksei Voitylov <aleksei.voitylov at bell-sw.com> 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.

More information about the core-libs-dev mailing list