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

Simon Tooke stooke at redhat.com
Tue Sep 22 18:32:20 UTC 2020


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.

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.

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.

I completely understand if it is rejected; after all the original was 
priority P4.

-Simon




More information about the jdk8u-dev mailing list