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

Michael McMahon michael.x.mcmahon at oracle.com
Mon Feb 24 06:12:50 PST 2014


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.

>> 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



More information about the net-dev mailing list