Hi Chris,
your fix is cool. I will assign the bug to you:)
a comment on this fix. The test changed system SecurityManager and it is
not executed with othervm mode. I think you need to rollback the change after
test. Otherwise it may affect other tests.
Thanks,
Felix
> On Jan 20, 2016, at 12:45 PM, Chris Hegarty <chris.hega...@oracle.com> wrote:
>
> On 20 Jan 2016, at 06:36, Chris Hegarty <chris.hega...@oracle.com
> <mailto:chris.hega...@oracle.com>> wrote:
>
>> Felix,
>>
>> On 14 Jan 2016, at 06:07, Felix Yang <felix.y...@oracle.com> wrote:
>>
>>> Hi all,
>>> please review the fix for
>>> test/java/net/SocketPermission/SocketPermissionTest.java, which fails
>>> frequently with "java.net.BindException: Address already in use".
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8065076
>>> Webrev: http://cr.openjdk.java.net/~xiaofeya/8065076/webrev.00
>>
>> My preference is to avoid getFreePort. It is problematic and I believe just
>> obfuscates
>> the intermittent failures further.
>>
>> In many of the test scenarios the “listening” socket can be created before
>> the specific
>> access control context and associated permission are created.
>>
>> I’ll see if I can get some time to try this out.
>
> I spent a little time on this today. I basically rewrote the test, but kept
> the
> same test scenarios. The use of data providers was cute, but not workable
> since there is no common supertype for the socket classes. I decided to
> just expand out the test cases manually. This will give the same test
> coverage, but should be stable since it creates the sockets first, on an
> ephemeral port, and then constructs the permissions appropriately given
> that port.
>
> http://cr.openjdk.java.net/~chegar/8065076/
> <http://cr.openjdk.java.net/~chegar/8065076/>
>
> The webrev diffs are almost useless, just review the new file, and compare
> test scenarios against the what is in the old file.
>
> -Chris.
