A Few Java ‘Gotchas’ to Watch Out For

It is hard to believe I have been working on Java code for over ten years. I remember getting started in Java working on JSPs or Java Server Pages and Servlets which included putting scriptlets in my JSPs. Later on, I learned how that was frowned upon by true Java programmers. As we develop our Java skills we learn from senior team members as well as from books and blogs we read. Today, we are going to go over some ‘Java gotchas’ and how to avoid them.

Date Calendar issues

The date and calendar in Java has been a major issue for a lot of new and experienced developers alike. One of the little differences that hang up developers is the fact that the Java API can be inconsistent. An example of this is Calendar.get(Calendar.DAY_OF_MONTH) is 1-based and Calendar.get(Calendar.MONTH) is 0-based this leads to quite a bit of confusion. My first interaction with Java time and dates was not a positive experience. The Java community has listened to the programmers talk about these issues and they have made a change in Java 8. Here is a quote from Oracle’s site that explains why changes were needed.

“Why do we need a new date and time library?

A long-standing bugbear of Java developers has been the inadequate support for the date and time use cases of ordinary developers.

For example, the existing classes (such as java.util.Date and SimpleDateFormatter) aren’t thread-safe, leading to potential concurrency issues for users—not something the average developer would expect to deal with when writing date-handling code.”

The new Java API is more intuitive than the previous version. I think this will help many new developers get up to speed and become productive in Java.  Through the addition LocaleDate and LocalTime in the Java 8 API the time reflects date and time that are more intuitive.

 Threading issues

1. run() vs start()

I remember reading early in my development career that we should try to avoid threading, if possible.There are a lot of issues and complexities that come from trying to use threads in Java. In the past I remember a fellow co-worker was working with Java threads and called the run() method, thinking this would start things off. He didn’t realize he needed to call the start() method instead, demonstrating this confusing part of the threading API.

2. Unsynchronized wait()

This is one that may hit us the first time we try to use wait.

Object object = new Object();

try {

object.wait(1000);

} catch (InterruptedException ie) {

}

 The code will compile, but when you run it, it will throw an IllegalMonitorStateException. We need to call the wait method on the object and enclose it in a synchronized block. This can confuse both novice and experienced Java developers who may not have a lot of threading experience.

3. ThreadLocal

A coworker of mine recently shared an issue they ran into with the ThreadLocal class.

The ThreadLocal class is a mechanism for making thread-specific information globally available within an application. This is accomplished by creating internal ThreadLocal objects for each thread and storing them in a weak hash map which is keyed by thread ID. The ‘get and set’ methods will only operate on the object that belongs to the current thread. However, problems can arise in a servlet application that makes use of thread pools and therefore reuses thread ids. The internal ThreadLocal object is automatically garbage collected when the reference count drops to 0 but this is entirely dependent on the garbage collection schedule. To ensure thread safety, the ThreadLocal object should be cleaned up after each operation.

 This post covered just a few Java ‘gotchas’ that developers may run into. Have you encountered others?