Last Lombok Refactoring

This is the last refactoring example of deadlocked Java code using the “synchronized” keyword.

This example is from a site called Rose India.

I was not able to really use Lombok for this example. The classes that deadlocked extended Thread, and the only method in those classes was the run() method. I did not know if annotating run() with the Lombok annotation would work. The method run() was not marked with the “synchronized” method in the original. Instead there were two synchronized blocks in the run() method. The two classes were using the same String objects to lock, which is why there was a deadlock.

So I decided to do by hand what Lombok does behind the screens. I created a private final object in each method and used those for one of the locks. Just as in the other examples, the deadlock was broken.

Here is the original;

Here is the output of the original:

Here is the refactored version:

Here is the output of the refactored version:


Image from Wikipedia page for the Indonesian province of Central Java, assumed allowed under Fair Use.

Third Lombok Synchronized Example

Here is another installment of my exploration into concurrency in Java. I have written about finding the Lombok library which uses annotations to reduce boilerplate in Java code.

One of the annotations provided by Lombok is @Synchronized. It is to replace the “synchronized” keyword and prevent some of the problems that can come with using the “synchronized” keyword. There are other annotations available via Lombok, but I have not looked at them.

Here is the third example of a program with a deadlock using the “synchronized” keyword that I refactored with Lombok. I got this example from the Java 2S site.

For this one I have also included the output of each of the programs.

Here is the program:

Here is its output:

There is a line that says “Ending method main”, but it does not end unless you kill the program.

Here is the program refactored with Lombok:

Here is the output of the refactored program:

Image from the Wikipedia page for the Indonesian province of West Java, assumed allowed under Fair Use.

Second Lombok Synchronized Example

Here is the second example of a program that deadlocks, with an example that I refactored using the @Synchronized annotation from Project Lombok.

This example was posted on one of the LinkedIn groups in which I first started asking about concurrency using the synchronized keyword. The basic idea to prevent deadlock is to mark the methods with the @Synchronized annotation. For one of them you should create a private, final object, and use the name of that object as the element for that annotation. For the other method that deadlocks I just use the annotation without an element.

Here is the original that was posted:

Here is the version with the Lombok refactoring:

I have a couple more examples before I get to my notes from No Fluff Just Stuff.


Image from the Wikipedia page for the Indonesian province of West Java, assumed allowed under Fair Use.



First Lombok Synchronized Example

I found some examples of Java programs that become deadlocked due to their incorrect use of the “synchronized” keyword. I decided to try to get them to work using the @Synchronized annotation provided by Project Lombok.

First, here is the example from the Really Big Tutorial.


Here is the same program with Lombok:

I will have a few more examples over the next few days.

Image from the Wikipedia page for Jakarta, a province in Indonesia. With Java, the name is usually based on coffee or Indonesia. Image assumed allowed under Fair Use.


A Closer Look At Project Lombok

This is a continuation of my look into concurrency in Java.

I found a library called Lombok that uses annotations to reduce boilerplate code. Instead of using annotations for metadata, it uses hidden APIs to alter the class files. Some people do not like this because it is voodoo, but it seems to get the job done. There is a possibility that at some point in the future it will stop working.

For threading, it has an annotation @Synchronized. It has other annotations as well. The voodoo for the @Synchronized annotation is that it will create a private object and inject a synchronized object locking on the private object that it created. There is another version that takes a java.lang.String as a parameter (or element as they are called for annotations). If you use this version, then you provide the name of the object you want to lock on.

Here is what the javadoc says: “Almost exactly like putting the ‘synchronized’ keyword on a method, except will synchronize on a private internal Object, so that other code not under your control doesn’t meddle with your thread management by locking on your own instance.” So I suppose you could do everything that this annotation does for you by providing your own objects. But using Lombok makes your code a lot easier to read.

It would be great if every time you used the “synchronized” keyword the javac compiler created a unique object for that method or block.

In the discussions on LinkedIn, a few people have mentioned that using the synchronized keyword can cause performance issues. I do not know if creating and using a different object degrades performance. I got the impression from the discussions that the performance issue is due to applications repeatedly getting a lock on the same object. I have read that object creation is now cheap, so I do not think that using different private objects for locks would be that big of a deal.

But I do think that it helps prevent deadlocks. I got a few examples of deadlocks from the internet, including one from the Really Big Tutorial, and one from the LinkedIn discussions. I was able to refactor them with Lombok to prevent the deadlocks. I did have to use both forms of the @Synchronized annotation: One with the optional java.lang.String element, and one without. Only using the no-element annotation did not prevent the deadlock.

I will post the deadlock examples I found on the internet as well as my changes with Lombok.

Image from Wikipedia article about Mataram (city), the largest city on Lombok and the capital of the province containing Lombok, assumed allowed under Fair Use.

Looking at Project Lombok

My look into concurrency continues. I am messing around with some of the comments that I have gotten from my posts on LinkedIn and Stack Overflow.

I also found a project called Lombok, named after one of the islands of Indonesia. It uses annotations to replace a lot of boilerplate in Java for a few tasks, including threading. It can handle getters and setters, equals and hashCode and logging as well as synchronization.

A few of the forums that I have been on have recommended looking at something other than the “synchronized” keyword, which Lombok seems to rely on. But it is still worth looking at.

Image from the Wikipedia page for West Nusa Tenggara, the Indonesian province which contains Lombok, assumed allowed under Fair Use.