Enthuware

Posted: **Sat Oct 13, 2018 9:52 pm**

filter(Predicate<T>) its a terminal operation here?

Posted: **Sat Oct 13, 2018 9:54 pm**

why i cant use strm1 again if i didnt use a terminal operation on it

: streamconsumed2.jpg (71.35 KiB) Viewed 6947 times

The attachment streamconsumed2.jpg is no longer available

Posted: **Sat Oct 13, 2018 11:00 pm**

Not sure what you mean here. Are you asking a question or just making a comment?

Posted: **Sun Oct 14, 2018 1:15 am**

Yep, im asking another question, when im seeing this question i saw something strange with this code

Posted: **Sun Oct 14, 2018 2:07 am**

You will need to post the code as code and not an image so that it can be tried out.

Posted: **Sun Oct 14, 2018 2:55 am**

Looking at the code, you can't filter the original stream after it has been filtered. So, on the third line you should use stream2 (which refers to the new filtered stream created out of the original stream) instead of stream1.

Posted: **Sat Dec 08, 2018 12:13 pm**

Hi! AFAIK, when you start a parallel stream, elements' processing splits into several threads, in a way that you can't know how it is ordered. Imagine a

Code: Select all

Stream.iterate(1, x -> x + 1).limit(1000).parallel()

And an intermediate operation chain like

Code: Select all

.filter(i->i>=1).filter(i->i<10).sequential()

From what I know, in my mind I think that this is what it happens:

- Source generates number 1
- Source generates number 2
----- Start parallel processing
- Number 1 travels through Thread 1
- Number 2 travels through Thread 2
- Thread 1 calculates filter i>=1. Number 1 passes
- Thread 2 calculates filter i>=1. Number 2 passes
- Thread 1 gets stuck cause I started your wonderful etsviewer, and my lazy Windows 10 falls asleep for a while
- Thread 2 calculates filter i<10. Number 2 passes
- Thread 2 arrives sequential. Number 2 entered first. Now waiting to reorganize the other elements
- My Windows 10 wakes up and Thread 1 calculates filter i<10. Number 1 passes
- Thread 1 arrives sequential.
- (Waiting for other threads and elements to arrive to this point)
----- Start sequential processing

From the trace made here, if I make a .forEach(System.out::println), I think it will print 21, and not 12.

Am I right? Or my mind is terribly wrong?

Posted: **Sat Dec 08, 2018 10:13 pm**

Seems ok but it is really not possible to validate what you are saying unless it accompanies with exact code that can be compiled and run.

Posted: **Mon Dec 10, 2018 1:21 pm**

Oh, sorry, of course!!

Code: Select all

		
Stream<Integer> myStrm1 = Stream.iterate(1, x -> x + 1).limit(1000);
Stream<Integer> myStrm2 = myStrm1.filter(i -> { return i>100 && i<900; });
myStrm2.forEach(System.out::print);
		
System.out.println();
		
Stream<Integer> myOtherStrm1 = Stream.iterate(1, x -> x + 1).limit(1000);
Stream<Integer> myOtherStrm2 = myOtherStrm1.parallel().filter(i->i>100).filter(i->i<900).sequential();
myOtherStrm2.forEach(System.out::print);

If you run this code, both output lines seem identical, but if my previous post was right, they should be distinct at any point. Perhaps if limit was 1000_000_000 and filter was i>100 and i<900_000_000, there would be a difference.

The concrete question is... is my reasoning right, although I can't prove it empirically? Cause if I'm right, the answer marked as correct isn't 100% correct actually. And if my reasoning is wrong, where am I making a mistake? everything related to parallel streams is very confusing to me.

Thanks in advance.

Posted: **Mon Dec 10, 2018 9:29 pm**

You need to put a print statement in the filter operation to see the difference in output of sequential and parallel. Something like

Code: Select all

filter(i -> { 
      System.out.println("Checking "+i);
      return i>100 && i<900; });

You are not seeing any difference in your output because you are printing the elements of the end result. Irrespective of how the stream is processed, the end result will always be the same.

Posted: **Tue Dec 11, 2018 12:51 pm**

Ok, I changed the code to this:

Code: Select all

		
Stream<Integer> myStrm1 = Stream.iterate(1, x -> x + 1).limit(20);
Stream<Integer> myStrm2 = myStrm1.filter(i -> { System.out.println("Checking i>3 & i<18: " + i);
						return i>3 && i<18; });
myStrm2.forEach(System.out::println);
		
System.out.println();
		
Stream<Integer> myOtherStrm1 = Stream.iterate(1, x -> x + 1).limit(20);
Stream<Integer> myOtherStrm2 = myOtherStrm1.parallel()
						.filter(i-> { System.out.println("Checking i>3: " + i); 
							return i>3; })
						.filter(i-> { System.out.println("Checking i<18: " + i);
							return i<18; })
						.sequential();										
myOtherStrm2.forEach(System.out::println);

And the output was:

Code: Select all

Checking i>3 & i<18: 1
Checking i>3 & i<18: 2
Checking i>3 & i<18: 3
Checking i>3 & i<18: 4
4
Checking i>3 & i<18: 5
5
Checking i>3 & i<18: 6
6
Checking i>3 & i<18: 7
7
Checking i>3 & i<18: 8
8
Checking i>3 & i<18: 9
9
Checking i>3 & i<18: 10
10
Checking i>3 & i<18: 11
11
Checking i>3 & i<18: 12
12
Checking i>3 & i<18: 13
13
Checking i>3 & i<18: 14
14
Checking i>3 & i<18: 15
15
Checking i>3 & i<18: 16
16
Checking i>3 & i<18: 17
17
Checking i>3 & i<18: 18
Checking i>3 & i<18: 19
Checking i>3 & i<18: 20

Checking i>3: 1
Checking i>3: 2
Checking i>3: 3
Checking i>3: 4
Checking i<18: 4
4
Checking i>3: 5
Checking i<18: 5
5
Checking i>3: 6
Checking i<18: 6
6
Checking i>3: 7
Checking i<18: 7
7
Checking i>3: 8
Checking i<18: 8
8
Checking i>3: 9
Checking i<18: 9
9
Checking i>3: 10
Checking i<18: 10
10
Checking i>3: 11
Checking i<18: 11
11
Checking i>3: 12
Checking i<18: 12
12
Checking i>3: 13
Checking i<18: 13
13
Checking i>3: 14
Checking i<18: 14
14
Checking i>3: 15
Checking i<18: 15
15
Checking i>3: 16
Checking i<18: 16
16
Checking i>3: 17
Checking i<18: 17
17
Checking i>3: 18
Checking i<18: 18
Checking i>3: 19
Checking i<18: 19
Checking i>3: 20
Checking i<18: 20

So, in this case, there is no difference between the serial and the parallel stream. I tried to limit the number of elements to 2000 instead of 20, filtering between 5 and 950, and still the same behaviour. Does the intermediate operation parallel() start several threads? Is it possible in any case that when the stream arrives sequential(), the elements are disordered?

Posted: **Tue Dec 11, 2018 10:15 pm**

Yes, parallel() causes the elements of the stream to be processed in parallel (using multiple threads). If you remove the call to .sequential() in the second case, you will see that filter is invoked on elements without any set order.

You can go through this document from Oracle to get more clarity: https://docs.oracle.com/javase/tutorial ... elism.html

Posted: **Wed Dec 12, 2018 12:37 pm**

Hello, and thank you so much for your response. I've tried to remove sequential() from the second stream, and it works as I expected from the beginning. Just to understand everything, and as my last question... does the call to sequential(), in any way, invalidate the parallel() operation? If we look at all these examples, it seems like it does like this: if the stream only has a parallel() intermediate operation, it works as parallel, but if it has a sequential() intermediate operation, the stream works in a sequential way. Is it ok?

Posted: **Wed Dec 12, 2018 8:54 pm**

Ideally, it shouldn't but it does. See this: https://stackoverflow.com/questions/357 ... sequential
They may change the implementation again. So the point is, as long as parallel operation is in force, you cannot assume the order of the elements. Once it is made sequential again, order will be preserved.

Posted: **Thu Dec 13, 2018 12:46 am**

Oh, ok, now everything makes sense! The most clarifying sentence is:

The stream pipeline is executed sequentially or in parallel depending on the mode of the stream on which the terminal operation is invoked.

That fits all the tests we have done. Thank you so much! And sorry for all the re-replys, but concurrency in general, and parallel streams in particular, are the hardest part in this exam and I need to understand them well.

Posted: **Thu Dec 13, 2018 10:57 pm**

Enthuware

About Question enthuware.ocpjp.v8.2.1897 :

About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :

Re: About Question enthuware.ocpjp.v8.2.1897 :