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

[Andrew Haley]

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.

> https://bugs.openjdk.java.net/browse/JDK-8072664
>
> and there's also:
>
> https://bugs.openjdk.java.net/browse/JDK-8150529
>
> Having to run a C program to generate the native constant files doesn't
> work when cross-compiling. Just running the preprocessor will work and
> is all that is needed.

Of course, yes.

> I think this is very low-risk (the post-patch output files can be
> compared against the pre-patch output files) and, as Aleksey says
> on the bug, avoids the need to try and hack around this when
> cross-compiling.

That's the reason for the fix, I know.

> The aarch64/shenandoah-jdk8u tree has been carrying this hack for
> JDK-8072664 since December 2013:

Understood.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671