The new specification looks fine to me. Thanks, Xuelei
On 1/10/2013 4:40 PM, Brad Wetmore wrote: > The third version is now out (minus test cases), and is ready in the > webrev.03 directory. > > http://cr.openjdk.java.net/~wetmore/6425477/ > > The only change is the API as we discussed. > > Brad > > > > > On 1/9/2013 7:21 PM, Brad Wetmore wrote: >> 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" >> implementation may not actually be strong. And like Max, I've also had >> concerns about "which provider". >> >> In my previous proposal laundry list for SecureRandom, I had something >> like: >> >> securerandom.strongAlgorithms=algname1,algname2.provname1,algname3 >> >> which addresses both issues. The property will contain a list of algs >> or algs/providers, and we'll iterate through them. If we can't create >> an instance of one of these, return a null. >> >> public static SecureRandom getStrongSecureRandom() >> >> Given these comments, I think I'm going to move forward on this. The >> application will do: >> >> SecureRandom sr = SecureRandom.getStrongSecureRandom(); >> >> if (sr == null) { >> // Decide if this is a problem, and whether to recover. >> // sr = new SecureRandom(); or return; >> } >> >> 3. Sean wrote: >> >> > There's an assumption that the securerandom.strongAlgorithm has been >> > configured appropriately. >> >> Exactly, we'll ship with default values for each platform, and >> programs/deployers can add/subtract as needed. >> >> 4. Xuelei wrote: >> >> > The 2nd one is to define a SPI method (pros: the >> > admin won't need to set the property. The admin does not always know >> > what kind of providers will be used at runtime). >> >> If I'm reading this comment right, given the pros of the current >> approach, I hesitate letting implementations make comparative strength >> decisions. >> >> Thanks! I should have a new version out tonight. >> >> Brad >> >> >>
