RFR 8024253: ThreadLocal random can use SecureRandom for the initial seed

[Guy Steele]

On Sep 16, 2013, at 1:02 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 09/16/2013 11:39 AM, Chris Hegarty wrote:
>> On some platforms, Windows, tunneling interfaces report a very "bad" mac
>> address, e.g.  00-00-00-00-00-00-00-E0. I wonder if it is worth skipping all
>> isVirtual() nifs?
>> 
> 
> Good idea.  This makes it impossible to also take advantage of Guy's
> de-uglification though. Leaving the following.
> 
> (This might stand as a record for the most expert attention
> spent on the least important issue ever in JDK :-)! Recall that
> the motivation is solely to act as a tie-breaker in the
> incredibly unlikely scenario of a cluster of communicating
> hosts all starting at the same time.)


+1

Okay, as long as we're obsessing: the code defends against the hardware
address being longer than 8 bytes.  Should the trailing bytes be the ones
dropped?  In a MAC address, I think they are the ones more likely to be
distinct (the leading bytes indicate manufacturer, yes?).  Then again,
does the Java interface provide any guarantees about the order in which
the bytes are presented in the array?

So how about this code?

                   if (bs != null) {
		       int m = Math.min(bs.length >> 1, 4);
                       for (int i = 0; i < m; ++i)
                           h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
		       if (m < 4) h = (h << 8) ^ bs[n-1-m];  // might include this byte twice, but this is the cheapest possible test for whether we *don't* want it
                       break;
                   }

:-) :-)

--Guy