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