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