Changeset: 4176e6cc499e
Author:darcy
Date: 2013-01-09 20:20 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4176e6cc499e
8005713: Simplify library support for repeating annotations in
java.lang.annotation
Reviewed-by: abuckley
+ src/share/classes/java/lang/annotation/Repeata
Changeset: 7612fe48be90
Author:darcy
Date: 2013-01-09 20:02 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7612fe48be90
8004730: Add language model support for parameter reflection
Reviewed-by: abuckley
! src/share/classes/javax/lang/model/element/Element.java
! src/sh
I don't see any reason why not. We just need to come up with a good
naming convention, and then we can add that into the Standard Algorithms
document.
The existing names were established years ago, based on functional
implementations rather than a specific algorithmic basis.
Brad
On 1/9/
At 09:45 AM 1/9/2013, Sean Mullan wrote:
>think it is unlikely that 2 providers would implement the same SecureRandom
>algorithm, since the names are not standardized like other cryptographic
>algorithms such as SHA-256, RSA, etc.
Can this be fixed? There really should be a flavor for this.
E
Thanks for the feedback. I also received some privately which had
similar comments.
Wrapping up several emails into some bullet points:
1. I like Sean's suggested tweak to the API. I'm thinking of adjusting
it slightly.
2. Xuelei has a point about my fallback of "most preferred"
impleme
On 1/9/2013 10:45 PM, Sean Mullan wrote:
> On 01/09/2013 06:41 AM, Xuelei Fan wrote:
>> I like this new proposal. Some minor comments here.
>>
>> 1. The name of SecureRandom.getStrongAlgorithm()
>>
>> In the specification of the method and java.security, the word
>> "strongest" is used to desc
Changeset: 4c8b37f159f9
Author:mchung
Date: 2013-01-09 16:58 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c8b37f159f9
7103957: NegativeArraySizeException while initializing class IntegerCache
Reviewed-by: darcy, mchung
Contributed-by: brian.burkhal...@oracle.com
! src/sha
It seems to me that setting a security property that always point to the
strongest algorithm is like creating an alias for it. How about we
generalize this idea?
In java.security,
alg.alias.securerandom.strongest = SUN:sha1prng
Every other provider-based security class can use it.
Thanks
Changeset: 86828e84654f
Author:mullan
Date: 2013-01-08 19:00 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86828e84654f
7019834: Eliminate dependency from PolicyFile to
com.sun.security.auth.PrincipalComparator
Summary: Add new java.security.Principal.implies method
Reviewe
On 01/09/2013 08:37 AM, Xuelei Fan wrote:
Form the implementation of SecureRandom.getStrongAlgorithm(), it is
possible that returned value are not "strong" (if the related property
is not defined). It's really confusing to the application when it
requires a real strong one (for example, for cert
On 01/09/2013 06:41 AM, Xuelei Fan wrote:
I like this new proposal. Some minor comments here.
1. The name of SecureRandom.getStrongAlgorithm()
In the specification of the method and java.security, the word
"strongest" is used to describe the algorithm. While the name use the
word "strong".
Form the implementation of SecureRandom.getStrongAlgorithm(), it is
possible that returned value are not "strong" (if the related property
is not defined). It's really confusing to the application when it
requires a real strong one (for example, for certificate generation),
but only get a normal o
Which provider will provide this strong algorithm? If multiple do, are they
equally strong?
I had proposed using alg names like "Native/Strong/NonBlocking" in the meeting.
Will it still of help?
-Max
On Jan 9, 2013, at 7:41 PM, Xuelei Fan wrote:
> I like this new proposal. Some minor commen
I like this new proposal. Some minor comments here.
1. The name of SecureRandom.getStrongAlgorithm()
In the specification of the method and java.security, the word
"strongest" is used to describe the algorithm. While the name use the
word "strong". I think the method name and specification s
One minor omission.
On 1/9/2013 12:44 AM, Brad Wetmore wrote:
NativePRNG reads seeds from /dev/random and nextBytes from /dev/urandom.
I added two new NativePRNG implementations which are completely
blocking or nonblocking. The "securerandom.strongAlgorithm" property
points to the blocking va
Greetings,
Thanks so much for all of the constructive feedback. I wasn't terribly
happy with the previous API proposal, and the comments reflected that.
Sean Mullan came up with a nice API idea which greatly simplifies the
goal of helping applications/deployers select a "strong" SecureRandom
16 matches
Mail list logo
