If you run the app twice and it generates the same vanity address, that rather implies that your kernel has completely run out of entropy and is feeding apps repeated data, so the PRNG on top is looping. I think it is maybe expected to happen if you try and generate vanity addresses - one reason to not do it, frankly. I'm not sure you can generate really huge quantities of cryptographically random numbers on a regular PC if left unattended, it has to get entropy from somewhere and without any user interaction the best it can manage is consuming its own interrupt timings. That's why GPG and friends tell you to mash the keyboard and wave the mouse around when making keys, which obviously you aren't doing in this case.
As far as I know companies or organisations that need enormous streams of crypto-strong random numbers use a hardware RNG that measures Johnson–Nyquist noise. Alternatively HAVAGE (
http://www.irisa.fr/caps/projects/hipsor/) may work well if you need random numbers on servers, but I haven't tried it for myself.
If the kernel
can run out of entropy, there is something seriously wrong about how it is generating random numbers.
It's a common misconception to think that generating large amounts of cryptographic quality random data requires large amounts of hardware randomness. The crypto community that actually understands this stuff - as opposed to the uninformed and those trying to sell products - have realized for decades that the right approach to generating random numbers for crypto is to use a random pool in conjunction with a cryptographic quality pseudo-random number generator. (PRNG) Bruce Shneier and Niels Ferguson's
Fortuna algorithm is a good example of a very well thought out version of this approach, but the basic idea is really simple: maintain a pool of random bits, use a cryptographically secure pseudo-random number generator to generate pseudo-random data from that pool in whatever amount is required, and as truly random data is generated in the system, mix it into that pool. The volume of truly random, and unknown to the attacker, bits required is small because the entropy of the pool never decreases. Even on a virtual machine generating 128bits of random data from network packet timings isn't too hard and can be done relatively quickly - hardware random number generators simply make that process faster and should be fed through a random pool + PRNG anyway to protect you if the hardware generator fails.
Smartcards are actually a very interesting example of this philosophy: to generate random numbers they sometimes have as little as a random seed built into the hardware at the factory and a
counter guaranteed to always increment. To generate a random number the counter is incremented, verified to have incremented properly, and then something like SHA256(seed + counter) is computed to generate the number. Less daring designs still collect environmental entropy and mix it into the pool with XOR, but in an application where compromise of the smart-card compromises the whole system anyway this seemingly insecure approach is still
not the weak link in the system.
Get yourself a copy of Shneier's
Cryptography Engineering and read it carefully. Frankly I'm kinda surprised, and a bit worried, to see you have such a basic misunderstanding of cryptography given you maintain bitcoinj.