RFR [9]: 8034174 Remove use of JVM_* functions from java.net code

[Chris Hegarty]

On 24/02/14 14:12, Michael McMahon wrote:
> On 24/02/14 14:09, Chris Hegarty wrote:
>> On 24/02/14 10:42, Michael McMahon wrote:
>>> On 23/02/14 08:55, Chris Hegarty wrote:
>>>> On 22 Feb 2014, at 17:23, Dmitry Samersoff
>>>> <dmitry.samersoff at oracle.com> wrote:
>>>>
>>>>> Chris,
>>>>>
>>>>> Didn't look to windows part. Unix part looks good for me. See also
>>>>> below.
>>>>>
>>>>> I'm a bit concerned because of mixing NET_* abstractions and direct
>>>>> call
>>>>> to OS functions. It might be better to create NET_socket etc.
>>>> Me too. It is already a mess. System calls should be used directly,
>>>> unless there is a reason not to do so.
>>>>
>>>>> We use NET_GetSockOpt/NET_SetSockOpt in one places and plain os
>>>>> functions in other ones it have to be unified.
>>>> If there is no reason to call the NET_ variant, then the system call
>>>> should be used.
>>>
>>> Seems like the big #ifdef in net_util_md.h on this is more or less
>>> redundant now
>>> since the #define of NET_xxx to JVM_xxx was its only purpose.
>>
>> The only difference between these now is that the bsd/linux variant
>> are defined in a separate file ( extern ), bsd_close/linux_close. I'm
>> not sure, but I think the use of extern is still required here.
>>
>
> I think extern would be okay in the other case though. All C functions
> are extern unless
> declared static afaik.

Thanks. I'll include extern, and remove the other definitions.

-Chris.

>
>>> I wonder would it also be useful to expand the comment just above those
>>> definitions
>>> that currently just relates to AIX and say which other operating systems
>>> it applies to
>>> and if we could identify which system calls it affects, and which mean
>>> the NET_xx
>>> functions must be used. Or maybe this is going beyond what you wanted to
>>> do here?
>>
>> Beyond ;-) There is still a lot of cleanup that I want to make to this
>> code, but I'd like to do it incrementally, starting with breaking the
>> dependency on the VM interface. This makes it easier, certainly from a
>> review point of view.
>>
>> -Chris.
>>
>>>
>>> Michael
>