Hello!
This enhancement was generously contributed by Peter Levart [1]. The
original webrev is found here [2].
The goal was to improve concurrent accessibility of the cache, while
maintaining some additional limitations dictated by the spec.
Would you please help review this fix?
BUGURL: h
I have not reviewed the tests, but the following is my deep-dive on the
code.
Mostly nits. I stopped making comments about javadoc style issues ("."
at ends of fragments, indentation problems), except where you were
making changes anyway. I realize the existing code has a bunch of
problem
Alright, it seems majority prefers RSASSA-PSS. I will update the webrev
and CSR accordingly.
Valerie
On 4/30/2018 12:37 PM, Sean Mullan wrote:
On 4/30/18 3:27 PM, Bradford Wetmore wrote:
Xuelei/Tony changed my mind. I'm now more preferring #2, since it's
in a 3rd party already. I'd still b
On 4/30/18 3:27 PM, Bradford Wetmore wrote:
Xuelei/Tony changed my mind. I'm now more preferring #2, since it's in
a 3rd party already. I'd still be happy with #1.
Brad
On 4/30/2018 11:40 AM, Valerie Peng wrote:
I reordered the names and missed to update some of the description.
#2 and #
Xuelei/Tony changed my mind. I'm now more preferring #2, since it's in
a 3rd party already. I'd still be happy with #1.
Brad
On 4/30/2018 11:40 AM, Valerie Peng wrote:
I reordered the names and missed to update some of the description.
#2 and #3 are from 3rd party providers. #1 is what I
#2. Otherwise, please don't use #3.
Xuelei
On 4/30/2018 11:40 AM, Valerie Peng wrote:
I reordered the names and missed to update some of the description.
#2 and #3 are from 3rd party providers. #1 is what I have in the webrev,
#4 is just a new alternative in case people may prefer it over #
Hello!
This is 8u-dev only bug fix.
It was noticed that the keytool from the latest JDK 8 update release
displays type of PKCS12 keystore as JKS.
Would you please help review the patch?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8193171
WEBREV: http://cr.openjdk.java.net/~igerasim/8193
I reordered the names and missed to update some of the description.
#2 and #3 are from 3rd party providers. #1 is what I have in the webrev,
#4 is just a new alternative in case people may prefer it over #1.
Can you all please re-confirm your preference is?
Thanks!
Valerie
On 4/27/2018 4:51
On 4/30/18 8:25 PM, Claes Redestad wrote:
Hi,
moving a couple of local permission constants to
sun.security.util.SecurityConstants ensures we delay and avoid loading
permission classes very early during bootstrap. Delaying load is
profitable since it's happening early enough (before
System
On 2018-04-30 15:05, Sean Mullan wrote:
Looks fine to me.
Thanks!
I think the TO DO comment on line 131 of ReflectionFactory can be
removed - it looks like a leftover comment which doesn't seem relevant
anymore.
Sure
/Claes
Looks fine to me. I think the TO DO comment on line 131 of
ReflectionFactory can be removed - it looks like a leftover comment
which doesn't seem relevant anymore.
--Sean
On 4/30/18 8:25 AM, Claes Redestad wrote:
Hi,
moving a couple of local permission constants to
sun.security.util.Securit
On 2018-04-30 14:47, Alan Bateman wrote:
This looks okay to me.
Thanks!
Just a few nits - the comment from AccessibleObject has moved to
SecurityConstants. I think it would be better to leave the comment in
AccessibleObject, then you can just comment the SecurityConstants
update with the
On 30/04/2018 13:25, Claes Redestad wrote:
Hi,
moving a couple of local permission constants to
sun.security.util.SecurityConstants ensures we delay and avoid loading
permission classes very early during bootstrap. Delaying load is
profitable since it's happening early enough (before
System.
Hi,
moving a couple of local permission constants to
sun.security.util.SecurityConstants ensures we delay and avoid loading
permission classes very early during bootstrap. Delaying load is
profitable since it's happening early enough (before System.initPhase1)
to contribute to delaying the in
14 matches
Mail list logo
