java-stream

Finite generated Stream in Java - how to create one?

浪尽此生 提交于 2019-12-02 21:43:19
In Java, one can easily generate an infinite stream with Stream.generate(supplier) . However, I would need to generate a stream that will eventually finish. Imagine, for example, I want a stream of all files in a directory. The number of files can be huge, therefore I can not gather all the data upfront and create a stream from them (via collection.stream() ). I need to generate the sequence piece by piece. But the stream will obviously finish at some point, and terminal operators like ( collect() or findAny() ) need to work on it, so Stream.generate(supplier) is not suitable here. Is there

How are lazy streams implemented in Java 8?

梦想的初衷 提交于 2019-12-02 21:36:26
I am reading Java 8, specifically the "Streams API". I wanted to know how streams can be lazy? I believe streams are just added as a library and there are no changes done to the language to support laziness. Also, I will be shocked if somebody tells me it's achieved through reflection. Why would you need reflection to get laziness? For example, consider this class: class LazySeq<T> { private final List<T> list; private Predicate<? super T> predicate; public LazySeq(List<T> input) { this.list = new ArrayList<>(input); } //Here you just store the predicate, but you don't perform a filtering /

Java 8 Stream vs Collection Storage

左心房为你撑大大i 提交于 2019-12-02 21:05:53
I have been reading up on Java 8 Streams and the way data is streamed from a data source, rather than have the entire collection to extract data from. This quote in particular I read on an article regarding streams in Java 8. "No storage. Streams don't have storage for values; they carry values from a source (which could be a data structure, a generating function, an I/O channel, etc) through a pipeline of computational steps." From the source: http://www.drdobbs.com/jvm/lambdas-and-streams-in-java-8-libraries/240166818?pgno=1 I understand the concept of streaming data in from a source piece

Java 8: Find index of minimum value from a List

有些话、适合烂在心里 提交于 2019-12-02 20:54:09
Say I have a list with elements (34, 11, 98, 56, 43) . Using Java 8 streams, how do I find the index of the minimum element of the list (e.g. 1 in this case)? I know this can be done easily in Java using list.indexOf(Collections.min(list)) . However, I am looking at a Scala like solution where we can simply say List(34, 11, 98, 56, 43).zipWithIndex.min._2 to get the index of minimum value. Is there anything that can be done using streams or lambda expressions (say Java 8 specific features) to achieve the same result. Note: This is just for learning purpose. I don't have any problem in using

What is the difference between Streams and Collections in Java 8 [closed]

与世无争的帅哥 提交于 2019-12-02 20:29:32
I'm learning about Streams in Java 8. I got confused about this concept: A collection is an in-memory data structure, which holds all the values that the data structure currently has—every element in the collection has to be computed before it can be added to the collection. In contrast, a stream is a conceptually fixed data structure in which elements are computed on demand. I don't understand. How can a Collection only hold values that must have been computed before they can be added to the collection? And also, what is meant by the comparison of a Stream with a fixed data structure? You

Java stream map and collect - order of resulting container

别等时光非礼了梦想. 提交于 2019-12-02 20:02:44
List<MyObject> myList = new ArrayList<>(); //populate myList here List<String> nameList = myList.stream() .map(MyObject::getName) .collect(Collectors.toList()); In above code, can I expect that order of MyObject names in nameList is always the same as the order of myList ? Yes, you can expect this even if you are using parallel stream as long as you did not explicitly convert it into unordered() mode. The ordering never changes in sequential mode, but may change in parallel mode. The stream becomes unordered either: If you explicitly turn it into unordered mode via unordered() call If the

Java 8: Preferred way to count iterations of a lambda?

假装没事ソ 提交于 2019-12-02 19:54:34
I face the same problem often. I need to count the runs of a lambda for use outside the lambda. E.g.: myStream.stream().filter(...).forEach(item->{ ... ; runCount++); System.out.println("The lambda ran "+runCount+"times"); The issue is that runCount needs to be final, so it cannot be an int. It cannot be an Integer because that's immutable. I could make it class level variable (i.e. a field) but I'll only need it in this block of code. I know there are various ways, I'm just curious what is your preferred solution for this? Do you use an AtomicInteger or an array reference or some other way?

RxJava vs Java 8 Parallelism Stream

╄→尐↘猪︶ㄣ 提交于 2019-12-02 19:10:44
What are all the similarities and diferences between them, It looks like Java Parallel Stream has some of the element available in RXJava, is that right? Rx is an API for creating and processing observable sequences. The Streams API is for processing iterable sequences. Rx sequences are push-based ; you are notified when an element is available. A Stream is pull-based ; it "asks" for items to process. They may appear similar because they both support similar operators/transforms, but the mechanics are essentially opposites of each other. Stream is pull based. Personally I feel it is Oracle's

Benefits of internal iterations

旧街凉风 提交于 2019-12-02 18:52:14
问题 I just wanted to know, what the real benefits of Internal vs External Iterations are and why it is better to use internal operations (that's what I heard at least). Is it also possible to delete elements of a collection while internally iterating over the collection? Like in the code example: I know that the code readability of internal iterations is better, but are there some other benefits like performance improvements? //List with Strings of Fruit-Names Iterator i = aList.iterator();

What implementation detail makes this code fail so easily?

别来无恙 提交于 2019-12-02 18:46:44
This question is not about the well-known and documented fact that HashMap is not thread-safe, but about its specific failure modes on HotSpot and JDK code. I am surprised by how readily this code fails with an NPE: public static void main(String[] args) { Map<Integer, Integer> m = new HashMap<>(0, 0.75f); IntStream.range(0, 5).parallel().peek(i -> m.put(i, i)).map(m::get).count(); } There is no mystery as to where the NPE comes from: in the .map(m::get) step while trying to unbox a null . It fails in about 4 out of 5 runs. On my machine Runtime#availableProcessors() reports 8, so presumably