[8u] RFR: JDK-8152545 Use preprocessor instead of compiling a program to generate native nio constants

[Hohensee, Paul]

Hi, Simon,

I've tagged the issue since it seems to have been reviewed.

Thanks,
Paul

On 9/23/20, 1:40 PM, "jdk8u-dev on behalf of Andrew Hughes" <jdk8u-dev-retn at openjdk.java.net on behalf of gnu.andrew at redhat.com> wrote:

    On 09:55 Wed 23 Sep     , Andrew Haley wrote:
    > On 22/09/2020 20:21, Andrew Hughes wrote:
    > > On 09:54 Tue 22 Sep     , Andrew Haley wrote:
    > >> On 28/02/2020 18:06, Simon Tooke wrote:
    > >>> Hello,
    > >>>
    > >>> I would like to request approval to backport of JDK-8152545 (Use
    > >>> preprocessor instead of compiling a program to generate native nio
    > >>> constants) to jdk8u for buildability reasons.  I've personally
    > >>> encountered toolchains where the current solution doesn't build.
    > >>>
    > >>> I had to modify the original webrev to get rid of the SO_REUSEPORT
    > >>> definition, as it isn't supported in JDK8.
    > >>>
    > >>> I've tested this on Windows and macos.
    > >>>
    > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152545
    > >>>
    > >>> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e2e318304252
    > >>>
    > >>> Modified webrev:
    > >>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8152545-jdk8/02/jdk.02
    > >>
    > >> Why is this being backported? There's no explanation in the bug report
    > >> and it doesn't seem to fit any of the usual criteria for a backport.
    > >
    > > I see explanations for this in both this e-mail and in the comments on
    > > the bug report.  There is also further detail in the comments of the
    > > linked bug,
    >
    > Not really, no. JDK 8u is an old release and the build system has, in
    > general, greatly improved since then. The obvious question to ask when
    > someone suggests back-porting a buld fix from 2016 is "Why now?" And
    > my suspicion was that there is no special reason to do it now. Hence
    > the question.
    >

    Ah ok. The situation here, as with a number of other fixes, is they
    have been fixed locally in various downstream repositories and build
    environments, but never in the upstream tree.

    I would prefer we try to minimise this divergence and get solutions to
    these issues upstream where possible.

    I suspect the reason these fixes weren't backported earlier is because
    it has not always been as easy as it is now to get fixes upstream. So,
    particulary with the older releases (6, 7 & 8), there is a legacy of
    fixes strewn around in various other places.

    Such fixes have often received much more testing in production
    environments than backports of newer fixes, by the sheer length
    of time they have been included in downstream packages.

    It's also possible that some bug fixes only become relevant as build
    environments change. Although the production build environment for
    legacy JDKs is likely to remain stable, the development build
    environment of those working on maintaining 8u is less so.

    Thanks,
    --
    Andrew :)

    Senior Free Java Software Engineer
    OpenJDK Package Owner
    Red Hat, Inc. (http://www.redhat.com)

    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222