JavaAntiPatterns

Collection of bad coding practices

Measure time intervals using System.currentTimeMillis()

with 5 comments

Well, what’s wrong with a common practice of measuring elapsed time in the code like this:

(bad)

long startTime = System.currentTimeMillis();
// ...
long elapsedTime = System.currentTimeMillis() - startTime;

The approach is based on an intuitive assumption that the values returned by currentTimeMillis() (in general, the current system time expressed as a number of milliseconds since midnight, January 1, 1970 UTC) grow smoothly and always are greater in the future than in the past. This is not always the case.

A simple example when this assumption fails is adjusting the system clock. On the most of the modern systems, correction of the clock is performed automatically by polling a value from the NTP server in a specific period of time. If this correction happens in the middle of your operation, the measured time interval will be wrong or even negative. Note that the typical computer clocks have an error in tens or even hundreds of milliseconds per hour that means that the correction offset will be up to few seconds if it is performed once a day.

It is safer to use the System.nanoTime() method which does not depend on a system clock, so it’s guaranteed that its value grows smoothly from the past to the future:

(good)

long startTime = System.nanoTime();
// ...
long elapsedTime = (System.nanoTime() - startTime) / 1000000; // ms

And remember that the nanoTime values has nothing to do with any real absolute time, so don’t try to use it for the Date objects, for instance.

See also: Inside the Hotspot VM: Clocks, Timers and Scheduling Events

Written by Alex

March 15, 2012 at 4:13 am

Posted in Threads

Tagged with

Null returned from a method returning a collection or an array

with 6 comments

Null should never be returned from a method returning a collection or an array. Instead return a empty array (a static final empty array) or one of the empty collections (e.g. Collections.EMPTY_LIST assuming the client should not be modifying the collection).

(submitted by Rand McNeely)

Written by Alex

November 11, 2009 at 5:10 pm

Posted in Collections

Tagged with , ,

Unneccessary thread safety of StringBuffer

leave a comment »

Use StringBuilder rather then StringBuffer, unless synchronization is required. StringBuilder is not thread safe, and therefore avoids the synchronization overhead of StringBuffer.

(submitted by Robert J. Walker)

Written by Alex

August 22, 2008 at 4:07 am

Posted in Strings, Threads

Tagged with , ,

Comparing URLs with ‘URL.equals()’

leave a comment »

Implementation of equals() in java.net.URL is based on a fancy rule saying that URLs of two hosts are equal as long as they are resolving to the same IP address. It is known to be incompatible with virtual hosting and should not be used.

For instance, URL.equals() would consider the URL of this blog (https://javaantipatterns.wordpress.com) to be equal to an URL of any random blog hosted on WordPress – that is obviously not true.

It is recommended to use java.net.URI objects instead.

P.S.
java.net.URL class is an absolute champion in a number of implemented antipatterns of equals() (and hashCode() as well):

Written by Alex

November 24, 2007 at 6:53 am

Posted in Networking, Objects

Tagged with ,

‘equals()’ and ‘hashCode()’ are context-sensitive

with 3 comments

equals() and hashCode() implementations should rely only on an internal object state. Making them dependent on other objects, context of use and other external conditions conflicts with the general contracts of consistency:

“For any reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false” [*]

“Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer” [*]

Violating those contracts may cause all kinds of weird and unpredictable behavior.

A known example of this antipattern is equals() and hashCode() in java.net.URL implementation where they are depending on information returned by a domain name server, rather than on actual stored URL data.

See also:

Written by Alex

November 24, 2007 at 6:20 am

Posted in Objects

Tagged with , ,

Not taking advantage of ‘toString()’

with 2 comments

Overriding toString() method gives you a cheap way to provide human-readable labels for objects in output. When the objects are used in GUI containers, such as JLists or JTables, it allows to use the default models and renderers instead of writing the custom ones.

Read the rest of this entry »

Written by Alex

November 22, 2007 at 11:16 pm

Posted in Objects, Strings

Tagged with ,

Instatiation of immutable objects

with one comment

Creating new instances of immutable primitive type wrappers (such as Number subclasses and Booleans) wastes the memory and time needed for allocating new objects. Static valueOf() method works much faster than a constructor and saves the memory, as it caches frequently used instances.

It is guaranteed that two Boolean instances and Integers between -128 and 127 to be pre-cached, thus you definitely should not use the constructor to instantiate them.

Read the rest of this entry »

Written by Alex

November 22, 2007 at 3:14 pm

Posted in Objects

Tagged with ,