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

Andrew Haley aph at redhat.com
Wed Sep 23 08:55:45 UTC 2020


On 22/09/2020 19:32, Simon Tooke wrote:
> 
> On 2020-09-22 4:54 a.m., 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.
>>
> The fix removes the need to compile and run a program to get various 
> runtime constants which are later compiled into the JDK.

OK.

> This is an impediment to cross-compiles, as the constants (some of which 
> are admittedly specified by standards) are those of the host, not target 
> platform.  So I think it's a good fix for that alone.

Ah, right.

> In addition, I've run into issues in windows and macos builds that this 
> will fix (see Aleksey Shipilev's comments).  At one time I needed this 
> patch to get the 8u macos build going, but I can't confirm that is still 
> the case due to other build issues.

Fair enough. Thanks.

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



More information about the jdk8u-dev mailing list