On 13 Oct 2016, at 09:46, Langer, Christoph <christoph.lan...@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

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.


Reply via email to