uniqueElements in parallel mode - encounter order

[Georgiy Rakov]

We work with promoted build 64. To be more precise the build I use for 
developing was downloaded from:
http://jre.us.oracle.com/java/re/lambda/8/promoted/ea/b64/bundles/windows-amd64/lambda-8-b64-windows-amd64-05_nov_2012.zip

We would appreciate greatly if you could promote new build with all the 
fixes.

Thanks, Georgiy.

On 30.11.2012 18:54, Paul Sandoz wrote:
> What revision are you working from?
>
> I don't observe such behaviour from the tip, encounter order is preserved for both sequential and parallel streams.
>
> Example output:
>
>     [testng] [1, 1, 8, 0, 1, 3, 5, 6, 5, 3, 9, 1, 5, 9, 8, 6, 6, 4, 7, 4, 4, 2, 7, 6, 7, 5, 0, 4, 0, 9, 7, 4, 1, 2, 5, 4, 4, 4, 5, 4, 3, 5, 4, 1, 9, 2, 2, 4, 0, 3, 6, 8, 0, 3, 6, 3, 1, 3, 2, 8, 7, 8, 2, 6, 5, 8, 2, 4, 4, 4, 0, 8, 3, 0, 2, 5, 0, 3, 8, 0, 9, 6, 7, 5, 1, 6, 5, 1, 0, 0, 9, 7, 1, 9, 7, 4, 3, 8, 8, 9, 8, 7, 1, 1, 7, 6, 0, 2, 3, 8, 2, 9, 7, 6, 1, 1, 5, 4, 9, 8, 3, 8, 2, 5, 9, 3, 1, 5, 3, 8, 5, 5, 3, 1, 3, 4, 7, 5, 9, 8, 8, 7, 8, 1, 2, 3, 2, 1, 9, 7, 1, 0, 2, 3, 0, 5, 3, 1, 6, 7, 3, 6, 3, 7, 7, 4, 4, 2, 9, 5, 7, 9, 2, 6, 5, 5, 4, 0, 0, 9, 0, 0, 8, 3, 7, 2, 8, 0, 6, 9, 3, 9, 8, 3, 8, 0, 8, 8, 1, 6, 5, 2, 0, 5, 1, 8, 8, 7, 5, 3, 0, 9, 1, 0, 2, 6, 0, 4, 0, 6, 9, 9, 8, 4, 4, 4, 2, 8, 2, 2, 9, 9, 0, 6, 3, 4, 7, 9, 2, 4, 4, 2, 1, 6, 6, 2, 6, 5, 4, 2, 6, 7, 1, 5, 6, 6, 9, 2, 9, 9, 2, 9, 5, 1, 5, 7, 7, 9, 3, 6, 5, 3, 4, 7, 7, 2, 6, 7, 1, 6, 1, 1, 3, 8, 0, 6, 4, 2, 0, 9, 0, 7, 1, 6, 7, 0, 5, 3, 8, 7]
>     [testng] [1, 8, 0, 3, 5, 6, 9, 4, 7, 2]
>
> Assuming that the input to the uniqueElements operation is not already sorted and declared as such then the implementation uses a LinkedHashSet or Set (if order is to be preserved or not respectively) to hold unique elements. It never explicitly sorts the input.
>
> Paul.
>
> On Nov 30, 2012, at 3:26 PM, Georgiy Rakov<georgiy.rakov at oracle.com>  wrote:
>
>> Hello,
>> *
>> uniqueElements()* method working in parallel mode does not preserve encounter order now. Consider following code. *result *will always contain sorted numbers in spite of shuffling, i. e. [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]. I could suppose this is the used algorithm artifact.
>>
>>    import java.util.ArrayList;
>>    import java.util.Arrays;
>>    import java.util.Collections;
>>
>>    public class UniqueElementsIssue1 {
>>         public static void main(String arg[]) {
>>             ArrayList<Integer>  data = new ArrayList<>();
>>             for (int i = 0; i<10; ++i) {
>>                 for (int k = 0; k<30; ++k) {
>>                     data.add(i);
>>                 }
>>             }
>>             Collections.shuffle(data);
>>             ArrayList<Integer>  result = new ArrayList<>();
>>             Arrays.parallel(data.toArray(new
>>    Integer[0])).uniqueElements().into(result);
>>         }
>>    }
>>
>>
>> While for sequential mode (Arrays.asStream) the encounter order is preserved.
>>
>> Could you please tell if this is considered as expected behavior and will be showed in spec; for instance something like following could be there.
>> /Having been called on stream in sequential mode, UniqueElements preserve encounter order.
>> Having been called on stream in parallel mode, UniqueElements doesn't preserve encounter order.
>> /
>> The code above is attached for your convenience.
>>
>> Thanks,
>> Georgiy.
>> <UniqueElementsIssue1.java>
>