The changes look fine to me also Chris.

Regards,
Sean.

On 22/01/16 14:49, Chris Hegarty wrote:
On 21/01/16 22:55, Felix Yang wrote:
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.

I will revert the change and have the test run in othervm mode.

I did do a complete test run with this change and it did not cause
any problems, but then again the policy is all permissions!

Thanks Felix.

-Chris.

> Otherwise it may affect other tests.

Thanks,
Felix
On Jan 20, 2016, at 12:45 PM, Chris Hegarty <chris.hega...@oracle.com
<mailto: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
<mailto: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/

The webrev diffs are almost useless, just review the new file, and compare
test scenarios against the what is in the old file.

-Chris.


Reply via email to