The real problem I originally brought up was that the unit tests were horribly slow due to blocking on /dev/random.
On Sun, Jan 17, 2010 at 8:21 AM, Sean Owen <sro...@gmail.com> wrote: > I think I must be missing something -- > > We don't use SecureRandom directly, so what would these effects have > to do with slow unit tests in our project? SecureRandom is referenced from the uncommons-maths class SecureRandomSeedGenerator via a private static final, so when SecureRandomSeedGenerator gets class loaded, we incur the penalty of the first SecureRandomSeed constructor's read of /dev/random. Since we fork for each unit test, this happens rapidly and quickly consumes the availble entropy on the system, leading to the blocking behavior we're seeing. Using a fixed seed doesn't solve the problem due to the way SecureRandomSeedGenerator is loaded by MerseneTwisterRNG Eliminating forking from the unit tests will probably be acceptable because I believe that Olivier has shown that the read from /dev/random only happens once either at SecureRandom class load time, or upon first call to its ctor. Drew
