> On May 7, 2020, at 7:52 AM, Kumar Srinivasan <kusriniva...@vmware.com> wrote:
>
> Hi Mikael,
>
> I may have created solinux when the macosx port was merged and in an effort
> to reduce the CPP conditionals.
> solinux = solaris + linux ie. Vanilla unix code vs Darwin code IIRC has
> Objective-C, MacOSX specific thread initialization etc.
Thank you for the background - it all makes sense now! :)
> I looked over the launcher related code looks ok to me.
>
> I did notice the \n endings for the messages that Brent pointed out.
Thank you for the review! The line ending should be fixed in webrev.01.
Cheers,
Mikael
>
>> On May 6, 2020, at 9:43 PM, Mikael Vidstedt <mikael.vidst...@oracle.com
>> <mailto:mikael.vidst...@oracle.com>> wrote:
>>
>>
>> I have always wondered what “solinux” is supposed to mean - though not
>> enough to actually ask anybody :)
>>
>> I’ll file a follow-up enhancement to cover renaming the files.
>>
>> Thank you for the review!
>>
>> Cheers,
>> Mikael
>>
>>> On May 4, 2020, at 7:59 AM, Roger Riggs <roger.ri...@oracle.com
>>> <mailto:roger.ri...@oracle.com>> wrote:
>>>
>>> Hi Michael,
>>>
>>> Looks good.
>>>
>>> Maybe just a future cleanup to rename files, since the "...so..." is
>>> refering to solaris.
>>>
>>> src/java.base/unix/native/libjli/java_md_solinux.h
>>> src/java.base/unix/native/libjli/java_md_solinux.h
>>>
>>> Regards, Roger
>>>
>>>
>>> On 5/4/20 4:49 AM, Alan Bateman wrote:
>>>> On 04/05/2020 06:12, Mikael Vidstedt wrote:
>>>>> Please review this change which implements part of JEP 381:
>>>>>
>>>>> JBS:
>>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8244224&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=W5VvD1owIGoUcbcRkcwixXGPkFLjHUFof2v6cxMqchk%3D&reserved=0
>>>>>
>>>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8244224&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=W5VvD1owIGoUcbcRkcwixXGPkFLjHUFof2v6cxMqchk%3D&reserved=0>
>>>>> webrev:
>>>>> https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~mikael%2Fwebrevs%2F8244224%2Fwebrev.00%2Fcorelibs%2Fopen%2Fwebrev%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=tQZIjuF5cIPs%2FNqTRtY2WtmwAgwa0iv205wQ9vk0vOQ%3D&reserved=0
>>>>>
>>>>> <https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~mikael%2Fwebrevs%2F8244224%2Fwebrev.00%2Fcorelibs%2Fopen%2Fwebrev%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=tQZIjuF5cIPs%2FNqTRtY2WtmwAgwa0iv205wQ9vk0vOQ%3D&reserved=0>
>>>>> JEP:
>>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8241787&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=rDvBE%2BJ2F1IIFC9fbA92rs0KZNgYPg0JZM2ynqp7mcs%3D&reserved=0
>>>>>
>>>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8241787&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=rDvBE%2BJ2F1IIFC9fbA92rs0KZNgYPg0JZM2ynqp7mcs%3D&reserved=0>
>>>>>
>>>>>
>>>>> Note: When reviewing this, please be aware that this exercise was
>>>>> *extremely* mind-numbing, so I appreciate your help reviewing all the
>>>>> individual changes carefully. You may want to get that coffee cup filled
>>>>> up (or whatever keeps you awake)!
>>>>>
>>>> I took a pass over the changes. I agree its a bit tedious. I'm sure there
>>>> will be a few follow up issues as there are opportunities for cleanup in
>>>> several areas. Just a few comments/questions from a first pass.
>>>>
>>>> ExtendedSocketOption.SO_FLOW_SLA is the Solaris specific socket option
>>>> that was terminally deprecated in 14. The patch removes the implementation
>>>> but leave the API (SO_FLOW_SA and jdk.net.SocketFlow). Do you want a
>>>> someone to take a follow-on issue to remove the API?
>>>>
>>>> ResolverConfigurationImpl.localDomain0 can be removed.
>>>>
>>>> The comment on mcast_join_leave in PlainDatagramSocketImpl.c has a
>>>> residual reference to Solaris.
>>>>
>>>> JISAutoDetect - might be simpler to just initialize EUCJPName to "EUC_JP".
>>>>
>>>> Socket.setTrafficClass(int) swallows exceptions to workaround strange
>>>> behaviour on Solaris. Tracked as JDK-8221487 so okay to leave it to that
>>>> issue if you want. There is also cruft in the old plain SocketImpl that to
>>>> work around eagerness to report "connection reset errors - I think we
>>>> should just leave that because the old socket impl is not used by default
>>>> and will be removed at some point.
>>>>
>>>> -Alan.
>
