How to Use Locks in Multi-threaded Java Program

Many Java programmers confused themselves like hell while writing multi-threaded Java programs e.g. where to synchronized? Which Lock to use? What Lock to use etc. I often receive request to explain about how to use Locks in Java, so I thought to write a simple Java program, which is multi-threaded and uses rather new Lock interface. Remember Lock is your tool to guard shared resource which can be anything e.g. database, File system, a Prime number Generator or a Message processor. Before using Locks in Java program, it’s also better to learn some basics. Lock is an interface from java.util.concurrent package. It was introduced in JDK 1.5 release as an alternative of synchronized keyword. If you have never written any multi-threading program, then I suggest first start with synchronized keyword because it’s easier to use them. Once you are familiar with working of multi-threading program e.g. How threads share data, how inter thread communication works, you can start with Lock facility. As I told you Lock is an interface, so we cannot use it directly, instead we need to use its implementation class. Thankfully Java comes with two implementation of java.util.concurrent.locks.Lock interface, ReentrantLock and ReentrantReadWriteLock, later provides two more inner implementation known as ReentrantReadWriteLock.ReadLock and ReentrantReadWriteLock.WriteLock. For our simple multi-threaded Java program's purpose ReentrantLock is enough.

Right way to Close InputStream and OutputStream in Java

For some unknown reasons many Java programmers are not very comfortable with IO package. I don't know why, but I have found them much more comfortable with java.lang and java.util than java.io. One possible reason of this could be that, writing IO code require a bit of C++ like programming, which involves doing clean-up, releasing resources once done etc. Since Java made coding a lot easier by taking care of memory management, unknowingly it also introduced bad practice of not releasing resource after use e.g. database connections, socket connection, files, directory, printers, scanners or any other scarce resource.

10 Programming Best Practices to Name Variables, Methods, Classes and Packages

What's in name? "A rose by any other name would smell as sweet" is a famous quote from William Shakespeare's classic Romeo and Juliet, but sorry to say, name matter a lot in programming and coding.  It's also said that code is the best document for any software, because any other document or comments can become outdated quickly, but code will always tell you truth; If code is then best document than names are most critical element of it. Every effort, small or big, invested while naming variables or methods, pays in both short term and long term. In fact, if you ask me just one coding practice to follow, It would definitely recommend giving meaningful names to your variables and methods. One reason, I push for this coding practice is because it improves readability of any algorithm or program drastically. Since every programmer spends more time reading code than writing, It would make a lot of sense to give meaningful names to your programming element. Readability is also one of the most important aspect of clean code. If you happen to read Clean code, the book by Uncle Bob, you would have seen a whole chapter on meaningful names, this just shows how important it is to name your variable, methods, classes and packages properly. Though these programming best practices are given from a Java programmer's perspective, they are equally useful in any other programming language. In fact, most of them are independent of any programming language and can be used while writing bash script, SQL stored procedures, C++ code and any other computer program. In fact you will value these practices more in case of shell script and database stored procedure because they don't have tools as smart as Java IDEs.

5 Articles to Learn about Shellshock Bash Bug

The year of 2014 is looking like a year of biggest software bug and vulnerabilities. Earlier this year, internet was bleeding by Heartbleed vulnerability and now it's shocked by ShellShock bug. To me it looks like even bigger than Heartbleed, just because it's a bug in Bash Shell, our own bash shell, most popular among all UNIX shells like C and K. Given most of the servers in Investment banks, Insurance companies, Clouds and e-commerce domain are Linux Servers with bash being most used shell, impact is quite large. I am sure people with Microsoft stack is smiling somewhere :), but wait, read the full article. First details of Shellshock bug emerged Wednesday last week, since then it has gone viral, both online and offline. People are busy talking about it and engineers are busy patching Servers, computers, routers, firewalls and other computing resources using vulnerable versions of bash. It has triggered patching almost everywhere. I am sure many of my readers are still puzzling with what is this ShellShock bug? For those, It's an example of an arbitrary code execution (ACE) vulnerability, which means attacker can execute their code on your vulnerable server. What this mean to you? Well if they can execute their own command they can do anything to your server and business. To start-with they can stop your servers, delete files, stole passwords and can take complete control for the machine, operating them remotely. Typically, arbitrary code execution vulnerability attacks are very sophisticated and require expert understanding of the internals of code execution, memory layout, and assembly language, which makes them very hard. Thanks to Bash ShellShock bug, now even a naive programmer can launch such kind of powerful attack to take control of vulnerable server. To give you an example, due to ShellShock vulnerability, anyone can take control of your web server by simply sending an HTTP request. This is massive, but fortunately impact is only limited to servers, where server side program pass user supplied information to Bash Shell, if your Java server doesn't do that, you are probably safe from that path of attack.