I wasn't content with just simply enjoying the benefits of quicker startup times. I had to know why.
Here's the short answer:
Java Bug 6202721 states that java.security.SecureRandom uses /dev/random rather than /dev/urandom even if /dev/urandom is specified because at the time (around 2004) /dev/urandom was not working properly. The bug has never been reversed now that /dev/urandom works quite well. Therefore, you have to fake it out by obscuring the setting by using /dev/./urandom to force the use of SHA1PRNG rather than /dev/random.
Here's the long answer:
/dev/random is a random number generator often used to seed cryptography functions for better security. /dev/urandom likewise is a (pseudo) random number generator. Both are good at generating random numbers. The key difference is that /dev/random has a blocking function that waits until entropy reaches a certain level before providing its result. From a practical standpoint, this means that programs using /dev/random will generally take longer to complete than /dev/urandom.
With regards to why /dev/urandom vs /dev/./urandom. That is something unique to Java versions 5 and following that resulted from problems with /dev/urandom on Linux systems back in 2004. The easy fix was to force /dev/urandom to use /dev/random. However, it doesn't appear that Java will be updated to let /dev/urandom use /dev/urandom. So, the workaround is to fake Java out by obscuring /dev/urandom to /dev/./urandom which is functionally the same thing but looks different.