title: How to implement a Java 8 Stream fluent API and lazily computed
body: <p>I would like to figure out a simple implementation equivalent to Java 8 <a href="https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html" rel="nofollow noreferrer">Stream</a> that would allow me to explore the development of query algorithms lazily computed (such as <code>map()</code>, <code>filter()</code>, <code>reduce()</code>, etc). <strong>NOTE</strong>: It is not my goal to achieve a better solution than Stream. On the other hand my only goal is to understand Stream internals. </p>
  
  <p>Yet, every implementation that I found is based on the <code>Iterable&lt;T&gt;</code>, such as the solutions presented in the following answers: </p>
  
  <ul>
  <li><a href="https://stackoverflow.com/a/30247144/1140754">How are lazy streams implemented in Java 8?</a></li>
  <li><a href="https://stackoverflow.com/a/30247332/6263808">streaming is not a container of data, but a container of logic</a></li>
  <li><a href="https://stackoverflow.com/a/30331518/1140754">Java8 internal iteration</a></li>
  </ul>
  
  <p>Yet, I do not feel comfortable with any of these solutions because:</p>
  
  <ol>
  <li>they are too verbose. </li>
  <li>they are not flexible for new query methods. The inclusion of new query methods requires structural modifications.</li>
  <li>Despite the query arguments, they do not take any advantage of new Java 8 features such as: first class functions or default methods.</li>
  <li>none of them use the <code>Spliterator&lt;T&gt;</code> approach that is used on <code>Stream&lt;T&gt;</code>.</li>
  </ol>
  
  <p>I know that <code>Spliterator&lt;T&gt;</code> was designed to allow partitioning and parallel processing, but I think that its unique iterator method (<code>boolean tryAdvance(Consumer&lt;t&gt;)</code>) could be exploited to new alternatives than those ones listed above. Moreover and as <a href="https://stackoverflow.com/a/31212695/1140754">stated by Brian Goetz</a>:</p>
  
  <blockquote>
    <p><code>Spliterator</code> is a better <code>Iterator</code>, even without parallelism. (They're also generally just easier to write and harder to get wrong.)</p>
  </blockquote>
  
  <p>So, is it possible to develop a more readable, simpler, concise and flexible implementation of a query API lazily computed and based on the same principles of the <code>Stream&lt;T&gt;</code> (except the parallel processing part)?</p>
  
  <p>If yes, how can you do it?  I would like to see simpler implementations than those ones listed above and if possible taking advantage of new Java 8 features.</p>
  
  <p><strong>Requirements</strong>:</p>
  
  <ul>
  <li>Do not reuse existing methods from Java 8 API</li>
  <li>The parallel processing feature is out of the scope of this question.</li>
  <li>If possible, and better, do not use the <code>Iterable&lt;T&gt;</code> approach.</li>
  </ul>
  
  <p><strong>The reason of my question?</strong> I think the best approach to learn a query API such as Stream is trying to implement those same methods by myself. I have already done it successfully when I was learning .net Linq. Of course that I did not achieve a better implementation than Linq but that helped me to understand the internals part. So, I am trying to follow the same approach to learn Stream. </p>
  
  <p>This is not so unusual. There are many workshops following this approach for other technologies, such as the <a href="https://github.com/timoxley/functional-javascript-workshop" rel="nofollow noreferrer">functional-javascript-workshop</a>, which most exercises ask for the implementation of existing methods such a: <code>map()</code>, <code>filter()</code>, <code>reduce()</code>, <code>call()</code>, <code>bind()</code>, etc… </p>
  
  <p><strong>Selected Answer</strong>: For now I considered <a href="https://stackoverflow.com/a/36901940/6263808">Miguel Gamboa’s answer</a> as my choice, instead of <a href="https://stackoverflow.com/a/36929610/6263808">Tagir Valeev’s answer</a> because the latter does not allow the implementaton of <code>findAny()</code> or <code>findFirst()</code> without completely traversing whole elements through the <code>forEach()</code> of <code>dataSrc</code>. However, I think that <a href="https://stackoverflow.com/a/36929610/6263808">Tagir Valeev’s answer</a> have other merits regarding the concise implementation of some intermediate operations and also on performance, since the <code>forEach()</code> based approach, reduces the overhead of the iteration code that mediates access to the data structure internals as cited by <a href="https://stackoverflow.com/a/31212695/1140754">Brian Goetz on point 2 of its answer</a></p>