Though this only works on Unix, so on Windows it uses the current time as a seed. It might get better results using #microsecondClockValue instead of #millisecondClockValue. And I'd think about just taking the microsecond value and sending it #hashMultiply instead of the weird things it's doing now. (bitXor with the identity hash of the UUIDGenerator instance? That depends on the randomness of identity hashes, which may or may not be very good.)
I agree less magic is better. And, more specifically, why would applying basically a linear transformation on a RNG seed produce "better random"? Note both xor and hashMultiply are essentially linear transformations. What is going on with how the RNG is using the seed to set itself up?
If the RNG seeds are assumed / preferred to be uniformly distributed over some range of values, I'd consider crypto-pre-digesting the seed candidate (because crypto hashes are engineered to uniformly spread small bit changes over the entire output, roughly speaking --- so one might even use consecutive values starting at 1 without penalty). Or, if /dev/urandom or equivalent is available, how about using it for the initial seed as well?
Andres.
