Hi Tim, > So, I'm not quite sure if it is supposed to be thread-safe... Can you > point me to something? Anyways, I ended up just making setSeed/nextByte > synchronized, hopefully that works for you.
Sounds great. After looking over what I sent, the volatile doesn't seem strictly necessary since all dangerous uses of those variables are in the synchronized methods. I couldn't find anything specifically requiring thread safety in the SecureRandom docs, but the Random [1] docs do specify that their impl is synchronized (plus running the same app I'm using under sun JVMs has never shown the ArrayIndexOutOfBounds (or other runtime exception)). Digging into the SPI specs didn't seem to include any mention of thread safety (or lack thereof) either, so it seems that either the SHA1PRNG could be threadsafe /or/ the SecureRandom.next(int) could synchronize on the engine - both would be fine by me. Not making either of them threadsafe is of course an option, but if kaffe goes that route, it might be best to toss a warning in the docs :) > Also, I added some new stuff so that it initially pulls from > "/dev/urandom" if it is available. So, if you experience anything > strange, holler. kickass! thanks =jr [1] http://java.sun.com/j2se/1.4.1/docs/api/java/util/Random.html#next(int) Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
