RFR(m): 8139233 add initial compact immutable collection implementations

[Eddie Aftandilian]

FWIW, at Google we have a patch against our JDK that randomizes hash
iteration order.  For test execution we randomize with a unique seed per
JVM invocation.  For production we force a specific seed for all
executions.  This approach catches most issues during automated testing,
but reduces the likelihood of an issue in production.

On Thu, May 5, 2016 at 2:04 PM, Stuart Marks <stuart.marks at oracle.com>
wrote:

>
>
> On 5/5/16 5:34 AM, Alan Bateman wrote:
>
>> I understand the goal, just wondering if there is something less devious
>> that
>> would make sense here. One idea is to use some portion of the Version,
>> say the
>> build number, so that it at least changes each week or build. That would
>> at
>> keeping the ordering consistent from run to run but it might change when
>> someone
>> updates.
>>
>
> Frankly I think we need to be more devious. We could change the iteration
> order on Wednesdays only, or perhaps only on full moons. :-)
>
> But really, if we're going to have randomized iteration order at all,
> we're better off doing it more frequently. That would flush out inadvertent
> order dependencies more quickly. If iteration order were to change, say,
> once per build, then order dependency bugs would masquerade as regressions.
> ("It works on b116 but fails on b117; what changed in b117?") I think that
> would be really confusing.
>
> s'marks
>