Seriously doubt Android uses (recent) OpenJDK HashMap code, otherwise many lawyers around the world would now be having heart attacks. Also, java.util.Random is plain congruent PRNG, having nothing to do with entropy pools, preseeded with nanoTime() at most.
-Aleksey. On 07.01.2013, at 16:19, Alexey Utkin <alexey.ut...@oracle.com> wrote: > I am sorry. Seems that I am out of discussion context, but did we get that > sort of problem: > > https://code.google.com/p/android/issues/detail?id=42265#c114 > http://forum.xda-developers.com/showthread.php?t=1987032&nocache=0 > > The article in Russian: > http://habrahabr.ru/post/164881/ > > Regards, > -uta > > On 27.12.2012 23:55, Mike Duigou wrote: >> I am responding on the StackOverflow thread. I will look into using >> ThreadLocalRandom. >> >> The random.next() is clearly a potential bottleneck but given that this >> happens only once per HashMap instance it is still unclear why a reasonable >> application would want to create hundreds or thousands of hash maps per >> second. >> >> Mike >> >> On Dec 27 2012, at 11:38 , Aleksey Shipilev wrote: >> >>> Looks very like dumb inlined java.util.Random? >>> Is there a security threat to use ThreadLocalRandom instead there? >>> >>> -Aleksey. >>> >>> On 27.12.2012, at 23:16, Zhong Yu<zhong.j...@gmail.com> wrote: >>> >>>> Reported by the SO question >>>> >>>> http://stackoverflow.com/questions/14010906 >>>> >>>> the HashMap constructor contains a CAS, which is kind of surprising. >>>> Could it be removed? >>>> >>>> transient final int hashSeed = >>>> sun.misc.Hashing.randomHashSeed(this); // CAS >>>> >>>> Zhong Yu >
