[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