Skip to main content

What distinguishes a collection from a stream? 

A collection and a stream are both ways to work with sequences of elements in Java, but they differ in several ways.

A collection is an in-memory data structure that holds a finite number of elements. Collections can be indexed and accessed in a random order. They typically provide methods for adding, removing, and querying elements.

A stream, on the other hand, is a sequence of elements that can be processed in a functional way, without the need to store them in memory. Streams are designed to support parallel processing of large data sets, and they can be created from various sources, such as collections, arrays, files, or other data sources.

Here are some key differences between collections and streams:

Storage: Collections store all their elements in memory, whereas streams do not necessarily store all their elements in memory. Streams can work with data from various sources, and they can process data on the fly, as it becomes available.

Mutability: Collections can be mutable or immutable, depending on the implementation. Streams, however, are always immutable and do not allow modification of their underlying data.

Iteration: Collections can be iterated over multiple times, and elements can be accessed in any order. Streams are typically consumed once and cannot be reused.

Lazy evaluation: Streams are evaluated lazily, meaning that intermediate operations are only performed when a terminal operation is invoked. This allows for more efficient processing of large data sets, as only the necessary data is processed.

Parallel processing: Streams support parallel processing, which means that large data sets can be processed in parallel, using multiple threads or processors.

In summary, collections are designed for storing and manipulating data in memory, while streams are designed for processing data in a functional, parallel, and lazy way.

Comments

Post a Comment

Popular posts from this blog

How to create Annotation in Spring boot

 To create Custom Annotation in JAVA, @interface keyword is used. The annotation contains :  1. Retention :  @Retention ( RetentionPolicy . RUNTIME ) It specifies that annotation should be available at runtime. 2. Target :  @Target ({ ElementType . METHOD }) It specifies that the annotation can only be applied to method. The target cane be modified to:   @Target ({ ElementType . TYPE }) for class level annotation @Target ({ ElementType . FIELD }) for field level annotation @Retention ( RetentionPolicy . RUNTIME ) @Target ({ ElementType . FIELD }) public @ interface CustomAnnotation { String value () default "default value" ; } value attribute is defined with @ CustomAnnotation annotation. If you want to use the attribute in annotation. A single attribute value. Example : public class Books {           @CustomAnnotation(value = "myBook")     public void updateBookDetail() {         ...
Post a Comment
Read more

Kafka And Zookeeper SetUp

 Kafka And Zookeeper SetUp zookeeper download Link : https://www.apache.org/dyn/closer.lua/zookeeper/zookeeper-3.8.3/apache-zookeeper-3.8.3-bin.tar.gz Configuration: zoo.conf # The number of milliseconds of each tick tickTime =2000 # The number of ticks that the initial # synchronization phase can take initLimit =10 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit =5 # the directory where the snapshot is stored. # do not use /tmp for storage, /tmp here is just # example sakes. dataDir =/tmp/zookeeper # the port at which the clients will connect clientPort =2181 4 char whitelist in command arguments 4lw.commands.whitelist =* Start ZooKeeper Server $ bin/zkServer.sh start Check zookeeper status dheeraj.kumar@Dheeraj-Kumar bin % echo stat | nc localhost 2181 stat is 4 character whitelisted argument  Check Kafka running status : echo dump | nc localhost 2181 | grep broker Responsibility of Leader in Zookeeper: 1. Distrib...
Post a Comment
Read more

Auto retries in REST API clients On Java On Ease

  Writing REST clients to consume API endpoints has become commonplace. While consuming REST endpoints, we sometimes end up in a situation where a downstream service throws some kind of transient error that goes away when the API call is retried. In such situations, we ask ourselves — “What if my API client was smart enough that knew how to retry a failed call?” Some of us go the extra mile to implement our own custom code that can retry API calls on error. But mind you, it is not only about knowing how to retry. The client also has to know when to retry and when not to. If the error is irrecoverable such as 400 — Bad Request, there is no point in retrying. It might also have to know how to back off and how to recover from the error. Implementing all this by hand, and then repeating it over and over again in every API client is cumbersome. It also adds a lot of boilerplate code and makes things even worse. But if you are a Spring/Spring Boot developer, you will be surprised to know...
Post a Comment
Read more