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

[Erik Joelsson]

New webrev with shorter lines in SocketOptionRegistry.java.template.

http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.02/

/Erik

On 2016-03-24 12:57, Erik Joelsson wrote:
>
>
> On 2016-03-24 12:15, Alan Bateman wrote:
>>
>> On 23/03/2016 16:14, Erik Joelsson wrote:
>>> :
>>>
>>> On 2016-03-23 12:13, Erik Joelsson wrote:
>>>> There are however 3 that, at least on Linux, are defined as an enum 
>>>> and not constants, which makes them unavailable to the 
>>>> preprocessor. These are:
>>>>
>>>> IPPROTO_TCP = 6
>>>> IPPROTO_IP = 0
>>>> IPPROTO_PV6 = 41
>>>>
>>>> I would say that this is fine. They have the same value on all our 
>>>> supported platforms and are actually part of the IP spec. I cannot 
>>>> imagine a reason for ever defining them differently. So the 
>>>> solution is to simply define these as constants in the java source.
>>>>
>>>> By fixing this, cross compiling new or existing platforms becomes 
>>>> much easier.
>>>>
>>>> I have verified this patch by manually comparing the output and by 
>>>> running the jdk_nio tests in JPRT.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152545
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.01/
>>
>> The hard coded values should be okay because they are standard, for 
>> example RFC 2292 defines IPPROTO_IPV6 as 41, TCP is protocol number 6.
>>
>> Is the #undef sun really needed? It otherwise looks good to me. We 
>> can fix up the very long lines at some point to get it consistent 
>> with the other code in this area.
>>
> When running this on Solaris without "#undef sun", the package line 
> ended up being "package  1 .nio.fs". That's the drawback/scary part of 
> using the preprocessor on something that isn't strictly C source, you 
> might get unexpected matches.
>
> If you want me to break up lines, I will do it.
>
> /Erik