DDevelopment & Design

Idiomatic Peeking with Java Stream API

The peek() method from the Java Stream API is often misunderstood. Let’s try to clarify how it works and when should be used.

Stream

 

Introduction

Let’s start responsibly by RTFM inspecting peek()’s user’s manual.

Returns a stream consisting of the elements of this stream, additionally performing the provided action on each element as elements are consumed from the resulting stream.
Sounds pretty straightforward. We can use it for applying side-effects for every consumed Stream element:

Stream.of("one", "two", "three")
  .peek(e -> System.out.println(e + " was consumed by peek()."))
  .collect(Collectors.toList());

The result of such operation is not surprising:

one was consumed by peek().
two was consumed by peek().
three was consumed by peek().

Stream/peek Lazy Evaluation

but… what will happen if we replace the terminal collect() operation with a forEach()?

Stream.of("one", "two", "three")
  .peek(e -> System.out.println(e + " was consumed by peek()."))
  .forEach(System.out::println);

It might be tempting to think that we’ll see a series of peek() logs followed by a series of for-each logs but this is not the case:

one was consumed by peek().
one
two was consumed by peek().
two
three was consumed by peek().
three

It gets even more interesting if we get rid of the forEach call:

Stream.of("one", "two", "three")
  .peek(e -> System.out.println(e + " was consumed by peek()."));

the result would be nothing:



As JavaDoc states:


Intermediate operations return a new stream. They are always lazy; executing an intermediate operation such as filter() does not actually perform any filtering, but instead creates a new stream that, when traversed, contains the elements of the initial stream that match the given predicate. Traversal of the pipeline source does not begin until the terminal operation of the pipeline is executed.

So, because of the lazy evaluation Stream pipelines are always being traversed “vertically” and not “horizontally” which allows to avoid doing unnecessary calculations. Additionally, the traversal is triggered only when a terminal method is present. Hence, the observed behaviour.


This is why it’s possible to represent and manipulate infinite sequences using Streams. (Because where do you store an infinite sequence? In the cloud?):


Stream.iterate(0, i -> i + 1)
  .peek(System.out::println)
  .findFirst();


The above operation completes almost immediately because of the lazy character of Stream traversal. Of course, if you try to collect the whole infinite sequence to some data structure, even laziness will not save you.


So, we can see that peek() can’t be treated as an intermediate for-each replacement because it invokes the passed Consumer only on elements that are visited by the Stream.


Unfortunately, Streams do not always behave entirely lazily.


Proper Usage


Further inspection of the official docs reveals a note:


This method exists mainly to support debugging, where you want to see the elements as they flow past a certain point in a pipeline

The point of confusion is the “mainly” word. Let’s have a peek(pun intended) at the English dictionary:




We can see that non-debugging usages are not forbidden nor discouraged.


So, technically, we should be able to, e.g., modify the Stream elements on the fly which would not be possible in the immutable, functional world. Let’s use the infamous mutable java.util.Date:


Stream.of(Date.from(Instant.EPOCH))
  .peek(d -> d.setTime(Long.MAX_VALUE))
  .forEach(System.out::println);

// Sun Aug 17 08:12:55 CET 292278994


and we can observe that the result is far away from the standard epoch, which means the mutating operation was indeed applied.


The problem is that this behaviour is highly deceiving because certain Stream implementations can optimize out peek() calls.


This gets clarified in the early draft of JDK 9’s docs eventually:


In cases where the stream implementation is able to optimize away the production of some or all the elements (such as with short-circuiting operations like findFirst, or in the example described in count()), the action will not be invoked for those elements. (…) An implementation may choose to not execute the stream pipeline (either sequentially or in parallel) if it is capable of computing the count directly from the stream source.

So, now it’s clear that it might not be the best choice if we want to perform some side effects deterministically.


According to this, peek() might not be even that reliable debugging tool after all.


Key Takeaways


    

  • The peek() method works fine as a debugging tool when we want to see what is being consumed by a Stream
    • 

  • It seems to work fine when applying mutating operations but should not be used this way because this behaviour is non-deterministic due to the possibility of certain peek() calls being omitted due to internal optimization
    • 

  • The discussion, whether mutation operations should be allowed or not, would never take place if we were restricted to operate only on immutable values
    • 

  • We have around 292276977 years before we run out of java.util.Date range
    • 



		

		




	


			

			

				

					
				

				

					

						
							
						
					

					

									

			

		

	
	








	


				

			
	



					

						
					

						

							 — Previous article
						


						

							Gerrit notifications via Rocket.Chat						

					

				
							
					

						

							Next article — 
						


						

							TouK Nussknacker - using Apache Flink made easier for analysts and business						

					

				
				

		


			


				
				

					

						You May Also Like					

				


				


					




	

		
DDevelopment & Design

		
		

						

				
Inconsistent Dependency Injection to domains with Grails
			


							

											

							
I've encountered strange behavior with a domain class in my project: services that should be injected were null. I've became suspicious as why is that? Services are injected properly in other domain classes so why this one is different?
 
Constructors experiment
 
I've created an experiment. I've created empty LibraryService that should be injected and Book domain class like this:
 
class Book {
    def libraryService

    String author
    String title
    int pageCount

    Book() {
        println("Finished constructor Book()")
    }

    Book(String author) {
        this()
        this.@author = author
        println("Finished constructor Book(String author)")
    }

    Book(String author, String title) {
        super()
        this.@author = author
        this.@title = title
        println("Finished constructor Book(String author, String title)")
    }

    Book(String author, String title, int pageCount) {
        this.@author = author
        this.@title = title
        this.@pageCount = pageCount
        println("Finished constructor Book(String author, String title, int pageCount)")
    }

    void logInjectedService() {
        println("    Service libraryService is injected? -> $libraryService")
    }
}
 
class LibraryService {
    def serviceMethod() {
    }
}
 
Book has 4 explicit constructors. I want to check which constructor is injecting dependecies. This is my method that constructs Book objects and I called it in controller:  
class BookController {
    def index() {
        constructAndExamineBooks()
    }

    static constructAndExamineBooks() {
        println("Started constructAndExamineBooks")
        Book book1 = new Book().logInjectedService()
        Book book2 = new Book("foo").logInjectedService()
        Book book3 = new Book("foo", 'bar').logInjectedService()
        Book book4 = new Book("foo", 'bar', 100).logInjectedService()
        Book book5 = new Book(author: "foo", title: 'bar')
        println("Finished constructor Book(Map params)")
        book5.logInjectedService()
    }
}
 
Analysis
 
Output looks like this:
 
Started constructAndExamineBooks
Finished constructor Book()
    Service libraryService is injected? -> eu.spoonman.refaktor.LibraryService@2affcce2
Finished constructor Book()
Finished constructor Book(String author)
    Service libraryService is injected? -> eu.spoonman.refaktor.LibraryService@2affcce2
Finished constructor Book(String author, String title)
    Service libraryService is injected? -> null
Finished constructor Book(String author, String title, int pageCount)
    Service libraryService is injected? -> null
Finished constructor Book()
Finished constructor Book(Map params)
    Service libraryService is injected? -> eu.spoonman.refaktor.LibraryService@2affcce2
 
What do we see?
 
  1. ✔
    Empty constructor injects dependencies.
  2. ✔
    Constructor that invokes empty constructor explicitly injects dependencies.
  3. ✘
    Constructor that invokes parent's constructor explicitly does not inject dependencies.
  4. ✘
    Constructor without any explicit call declared does not call empty constructor thus it does not inject dependencies. 
  5. ✔
    Constructor provied by Grails with a map as a parameter invokes empty constructor and injects dependencies.
Conclusion
 
Always explicitily invoke empty constructor in your Grail domain classes to ensure Dependency Injection! I didn't know until today either!
						

					
									

			
		


	






	

		
DDevelopment & Design

		
		

						

				
Sygnalizacyjne ABC
  • byTouK
  • August 1, 2008
			


							

											

							Poniższy artykuł oparty jest na wspaniałej pozycji książkowej “System Sygnalizacji nr 7 G. Danielewicz, W.Kabaciński”. Gorąco zachęcam do…