How the LinkedList class in Java works

I will explain how to perform operations like add, push, pop, poll, etc on LinkedList and what they mean. At first, it may seem a bit confusing, but I hope this article resolves a few conflicts.

A simple LinkedList of Strings declaration and definition looks like this:

There are several ways to add new elements to a LinkedList, but they mean and do different things. I will show you how each function works one by one.


One of the first methods you might encounter to add an element to a LinkedList is add. You can make use of add function in this manner:

Now let’s try to do the same with push!


We can conclude from this that add puts the element at the first position and then moves on to further positions. push on the other hand inserts elements quite like a stack. The element that is inserted first is the last when we traverse the linked list.

Let’s look at ways to fetch elements from the LinkedList. For this, we need to assume that the linked list already has some elements. Assume that for the subsequent examples, the LinkedList contains elements added using the add method like above.


Just a reminder that elements are added in the same fashion as in add.

Since pop and poll are nearly the same (poll returns null when the list is empty whereas pop throws an exception) I will not discuss poll.


Just a reminder that elements are added in the same fashion as in add.

As can be seen, pollFirst and pop function produce similar output.


Just a reminder that elements are added in the same fashion as in add.

And finally, pollLast!

Why people play MOBA

Usually, a lot of things in life are based on actions and consequences. When you act on something you can somewhat (if not fully) expect what the consequences will be. This theory has way too many variables in games like LoL where prediction on whether you will be the victor or loser depends on a multitude of configurations, players, their states of mind, their alertness, knowledge of the game, reflexes just to name a few. Non-scientifically you could even say these games are equivalent to gambling! That’s how unpredictable they are.

Victory depends not only on you but also on how your team plays, but at the same time without you your team will lose. It depends on the enemy team as well, and each and every player contributes to their team’s fate.

“Mayhaps this is a game of luck, like battleship”, you might say, but think about the hours of practice and the experience people have gained in order to control the turn of events in the game! It’s like reliving a war every time. There’s a Japanese saying which goes like, “A war is won before it is fought”. Mayhaps wars are inevitable, and mayhaps people are forced to join it even if it’s against their will. Mayhaps even the above quote is more intuitive than it seems.

But we don’t know unless we play :3

The confusing yet awesome behaviour of the DatagramSocket class

One of the recent projects that I am doing involves using UDP datagrams for communication. The DatagramSocket class in Java enables me to use that feature. At first, I wasn’t aware of all the features of the class, but as I started coding and explored different methods of using that package, several more things became clear to me. Well, firstly the documentation and tutorials that I looked up to understand how to use the class gave me a very minimalistic approach to using it. So, let me clarify how this class manages the network and how you can use this.

Let’s start with the constructor. For a minimalist working server, you must provide a port (otherwise packets might not get delivered to you). Basically, the DatagramSocket class takes care of listening to a port and sending data from that same port (if needed). It does not automatically send ACKs when a packet arrives. It listens, halts the process till data arrives.

A client on the other hand does not require a port to be specified in the constructor for minimalist working. Why? Because we are assuming that the client is not listening for any data (for the time being). It only sends the provided data to a specific port specified by an InetAddress. Now there is an important thing to understand about all this. If a port is not specified by the client, it randomly chooses one. Not specifying a port does not mean that a port is not required by the client to send the data! When the DatagramPacket arrives at the server’s end, the server can find out from the packet several things like the InetAddress of the source and the port through which the packet was sent. This allows the server to send data to that source through it’s address and on the port that it’s using.

The conclusion that can be drawn from these facts is pretty cool. A thread that’s listening on a port can receive packets from multiple sources, and in the same way a thread that’s sending packets can send them to different hosts!

The real important thing to remember is that you cannot use the same socket simultaneously for sending and listening. If a socket is listening on a certain port, you need to either make it stop listening and send your packet away or you need to open another socket to do so.

Of course, it is not possible to listen on multiple threads using just one socket. For this reason, one of a good architecture designing techniques for such a mechanism is as follows:

  • Listen on one socket
  • Send packets using another socket