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

Andrew Haley aph at redhat.com
Wed Mar 4 11:33:19 UTC 2020

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://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the core-libs-dev mailing list