Thanks Chris. On 02/ 8/12 10:47 AM, Chris Hegarty wrote: > On 08/02/2012 09:35, Xuelei Fan wrote: >> Looks fine to me. >> >> Interesting fix that making use of the class loading priorities. > > The 'Initialization on Demand Holder idiom' is used in other places in the > platform. I think it suits well here, if creating a SecureRandom at this point > is expensive. Especially if it may not be needed. > > Not directly related but "// should not happen". Should this throw an Error? > I've seen this in other places too, certainly can be handled separately and > not > a blocker for this particular fix.
I don't throw an error because it is permitted to generate a timestamp token without a secure random number. Of course, if the generator cannot be initialized successfully then that suggests a JRE configuration problem which may eventually result in an error. > > -Chris. > >> >> Xuelei >> >> On 2/8/2012 5:18 PM, Vincent Ryan wrote: >>> Please review the following change: >>> http://cr.openjdk.java.net/~vinnie/7142339/webrev.00/ >>> >>> for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142339 >>> >>> It employs lazy initialization to avoid the overhead of creating a secure >>> random number generator in code that never uses signature timestamping. >>> >>> Thanks. >>
