AF_INET6 support
Chris Hegarty
chris.hegarty at oracle.com
Tue Oct 18 10:57:01 UTC 2016
On 13 Oct 2016, at 09:46, Langer, Christoph <christoph.langer at sap.com> wrote:
>
> Hi Chris,
>
>>> I’ve got a question regarding AF_INET6.
>>>
>>> In jdk native code you’ll still find lots of code guarded by “#ifdef AF_INET6”.
>> I’m wondering if there are still supported build environments where AF_INET6
>> is not defined. Or is it time now to assume AF_INET6 and remove this guarding?
>> Here at SAP we don’t support non AF_INET6 build environments for quite a long
>> time already. But probably there are scenarios out in the Java world where only
>> IPv4 builds are done??
>>>
>>> Maybe you can shed some light on this and/or give your opinion?
>>
>> A while back we did consider removing #ifdef AF_INET6, so that the
>> code could be cleaned up and made more readable, but we never got
>> around to it ( it was just lower priority than other tasks ). I do remember
>> fixing, or sponsoring, a change in the last year or so, where an #ifdef
>> AF_INET6 was missing, that make me think that it was good that we
>> did not remove these ( i.e. the person that filed the bug had a good
>> use-case for building without IPv6 support ). I’ll see if I can jog my
>> memory by looking through history.
>
> Ok, it would really be great if you could find more information about that case where #ifdef AF_INET6 was missing and it lead to problems.
>
> But if nobody really does IPv4 only builds and tests the results, I doubt that the IPv4 only scenario would work or even build. Then I think it was likely that somehow unguarded IPv6 code sneaks in or has already done so...
>
> In case it can be removed it would really make the code more readable in several places. So, as I'm still doing cleanups, I could also take care of removing those #ifdefs at the places where I'm going. Just let me know.
It appears that we do not have a requirement to be able to build IPv4
only. So, it should be possible to do the clean up that you are
suggesting.
If possible, can the change be kept as a single separate JIRA issue,
so that we can easily identify the change in the future, if required.
-Chris.
More information about the net-dev
mailing list