Re: AF_INET6 support

2016-10-18 Thread Chris Hegarty
On 13 Oct 2016, at 09:46, Langer, Christoph  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.



RE: AF_INET6 support

2016-10-13 Thread Langer, Christoph
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.

Thanks
Christoph



Re: AF_INET6 support

2016-10-13 Thread Alan Bateman



On 13/10/2016 07:19, Langer, Christoph wrote:


Hi networking experts,

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?


It dates back to when IPv6 support was initially added and when there 
wasn't support on all platforms. Also there was a long period where it 
was supported to cross build to older (mostly embedded) platform that 
didn't have IPv6. I'm not aware of any now and don't see any reason not 
to clean this up.


-Alan


Re: AF_INET6 support

2016-10-13 Thread Chris Hegarty
Christoph,

> On 13 Oct 2016, at 07:19, Langer, Christoph  wrote:
> 
> Hi networking experts,
>  
> 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.

-Chris.