The reason a loop is needed here is that both the TCT and UDP servers must
listen on the same port number. With your fix, the TCP server finds a free
port, but I doubt if it's free for the UDP server.
--Max
> On Jul 8, 2016, at 2:35 PM, John Jiang wrote:
>
> Hi,
> Would you like to review th
Your change looks fine to me - and another shell script zapped.
Thanks.
> On 7 Jul 2016, at 23:43, Rajan Halade wrote:
>
> May I request you to review this small patch. I am not able to reproduce the
> failure so I enhance the test itself to get rid of shell script. Since
> temporary key gene
On 07/07/2016 11:28 PM, Weijun Wang wrote:
I know that a "@run main/policy=p" tag will be translated to
-Djava.security.policy==p and the system default
java.home/conf/security/java.policy will be ignored, and sometimes it's
necessary to copy some lines from there to the test's own policy file.
Looks fine.
--Sean
On 07/07/2016 05:11 AM, Tim Du wrote:
Hi Sean:
Thank you for reviewing the codes.
I updated the title for this bug and added othervm for the tests that
add but not remove their own provider. Also corrected the typo. New
webrev is available here:
http://cr.openjdk.java.net/~t
Hi Max,
thank you for pointing this out. Sure, if this change will break
existing certificates handling we shouldn't add this restriction.
If you don't mind I'll wait a little bit if anyone else wants to share
his/her opinion on that topic and if not close it as "Not an issue" as
you suggested
Hi Tim
Are we seeing new failures in these tests?
I am asking this question because once upon a time (4 years ago) I was involved
in several RFEs [1][2][3] to do some similar the same cleanup. Some tests were
put into othervm mode, but for most others, we tried our best to make them
runnable i
On 07/08/2016 11:23 AM, Wang Weijun wrote:
Hi Tim
Are we seeing new failures in these tests?
I am asking this question because once upon a time (4 years ago) I
was involved in several RFEs [1][2][3] to do some similar the same
cleanup. Some tests were put into othervm mode, but for most others,
Thank you Max for reviewing!
On 08.07.2016 3:41, Wang Weijun wrote:
Change looks fine.
Only one thing: why is the following @modules tag needed?
java.security.jgss/sun.security.krb5.internal.crypto
It's a copy\paste error, I'll remove it before pushing.
With kind regards,
Ivan
Thank
Hello!
I'd like to backport this fix into jdk8u-dev.
The fix is essentially the same as in jdk9, but could not be used
verbatim because of the code derivation.
Bug: https://bugs.openjdk.java.net/browse/JDK-8160518
Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d5c6e8bad2d
Jdk9 revie
Hi,
Please review this simple code cleanup:
http://cr.openjdk.java.net/~xuelei/8159009/webrev.00/
The javax.crypto.ExemptionMechanism.finalize() is implemented as:
/**
* Ensures that the key stored away by this ExemptionMechanism
* object will be wiped out when there are no mor
Change looks fine to me.
Thanks
Max
> 在 2016年7月9日，10:22，Xuelei Fan 写道：
>
> Hi,
>
> Please review this simple code cleanup:
>
> http://cr.openjdk.java.net/~xuelei/8159009/webrev.00/
>
> The javax.crypto.ExemptionMechanism.finalize() is implemented as:
>
>/**
> * Ensures that the k
11 matches
Mail list logo
