Juixe Techknow » Java

Top Worst Java Errors

TechKnow — Tue, 09 Mar 2010 06:26:07 +0000

I’ve had my fair share of Java bugs. There is a stage in a programmer’s career that he or she either knows that they rather manage a convenience store or that they can debug common Java errors just by the way the code smells. Here are my list of worst common Java bugs I have been frustrated to solve. These issues have come up more than once, most often in code that I inherited, and had to fix under a time crunch or tight deadline.

mkdir
I’ve had to fix a few bugs related to the mkdir() method in the File class. The mkdir() method creates or makes a new directory. The mkdir() method only creates one directory. But in many situations, especially if the end user is supplying the path of the directory to be created, you will need to crate a whole new directory hierarchy. Often times you will create a directory and subdirectories at one time. In these situations, you want to use the mkdirs() method instead.

Index Of
Most software bugs are caused by assumptions made by the programmer. One common assumption I see developers making is that file names have only one period to separate the file name from the file extension. It is common to see code that finds the first period and everything after that period is assumed to be the extension. Other assumptions regarding file names include that extensions are three characters long or that the file name does not have special characters. The following code snippet is a dramatization of code I have seen in the field, which incorrectly tries parse the file extension.

String filename = "a.file.path.ext";
int index = filename.indexOf(".");
String extension = filename.substring(index);

A different approach, which would have the desired result is to use the lastIndexOf() instead.

Null Equals
I’ve seen a whole slew of null pointer exceptions due to this sort of Java bug where a possibly null object reference will be used to check the equality of a hard coded constant. Here is the code snippet of what I mean.

boolean equals = maybeNullObjectReference.equals("CONSTANT");

The object reference may be null, so you need to check for null values. I found that if you switch your thinking, you can write less code and still achieve a better solution that having to constantly check if the object is null. A safe approach is to use a object that you know is not null, the constant value.

boolean equals = "CONSTANT".equals(maybeNullObjectReference);

Equals
Yet another Java bug that can be easy to miss is the use of the Java equals operator instead of the equals() method. The equals operator returns true if the two object references you are testing point to the same object instance. The equals operator compares the equality of the object references, not the object values but since it reads the same it is easy to overlook.

Map Key
The worst Java bug that I had to ever deal with involved the use of mutable objects as keys in hash maps. The implementation of the Java HashMap is really simple, the hash code of the key is used to locate the bucket in which to store the map entry, which consists of the key/value pair. Once you put a key/value pair in a hash map you should not change the value of the key, ever, in any way that changes the hash code. If the key is changed where it generates a new hash code, you will not be able to locate the correct bucket in the HashMap that contains the key/value pair. I had a scenario where key/value pairs were stored in a HashMap, then the keys where updated generating a new hash code, and there after the value was not able to located.

Don’t Turn a Code Review Into a Code Rant

TechKnow — Wed, 22 Jul 2009 20:54:48 +0000

In programming circles and when talking about code, I’ve often hear mentioned the Perl slogan “There’s more than one way to do it.” Thinking about the many ways we do it, whatever feature ‘it’ represents, I believe that the root cause of many of the software bugs we encounter are because engineers implement the feature in more than one way, then refactor it down the line, then add new conditions, then forgot how it did what it did. This often occurs because programming is like fashion, each season brings about a set of new best practices and technologies. We update the implementation to adapt to the current best practices, new technologies, and new features and don’t remove old bit rotten code.

Recently I a debate with a fellow engineer whose code I reviewed. As it is often the case, we had some existing functionality which we wanted to update with a feature. Most of the code review revolved around one existing method whose existing code looked something like the following.

public void setValue(DataRow dr) throws DataException {
  dataHelper.setValue(dr, false, true);
}

For the sake of this example, imagine that DataRow is a map of data that represents a row of data from a database and contains the meta-data of the columns it contains. The new functionality need to support a DataRow with a less number of meta-data, columns, than normally expected. We called this new feature partial value and so it was initially implemented as follows.

public void setValue(DataRow dr) throws DataException {
  dataHelper.setValue(dr, false, true);
}

public void setPartialValue(DataRow dr) throws DataException {
  setPartial(true);
  setValue(qube);
  setPartial(false);
}

Believe it or not, I had a very difficult and long drawnout debate with the engineer that implemented the above code. In my mind, there is no debate, the above code can be made to improve. In the engineer’s mind, this was good enough for this feature for the time allotted for the the current specifications for this release and for whatever other reason he counjured up.

One of the concerns I originally brought up with the initial implementation of setPartialValue was that if the setValue method throws an exception after having set the partial state to true, then the code will break out of both methods leaving an improper partial state behind. This will cause problems because the partial boolean field will have an invalid state which will caused problems if you the setValue method is called at a later point. Another problem, with this sort of style of programming, is the following scenario. Imagine that instead of a simple primitive boolean the partial property required an object reference that retained a lot of memory and you had the same exception, the memory for that field might not be garbage collected.

The sort of bugs that can be caused by the above implementation lead me to the following rule of thumb: Avoid instance fields. Always question the need for instance property. Try to be a team player and pass the object reference as a parameter down the stack. If you only need this little bit of state information for a method call, pass it as a parameter!

I couldn’t believe we had this much disagreement over three lines. At that moment I felt that code reviews are another form of micromanagement, but then I remembered who is the one that gets called if there is a bug in the system…. Yeah, me! The approach I was advocating did not require a object instance to keep the state of a boolean, which was only used within the context of the setPartialValue method call. In my approach the set/getPartial methods are not needed and it could have been refactored to the following.

public void setValue(DataRow dr) {
  setValue(dr, false);
}

private void setValue(DataRow dr, boolean partial) {
  dataHelper.setValue(dr, false, true, partial);
}

public void setPartialValue(DataRow dr) {
  setValue(dr, true);
}

The engineer countered that it “does not look nice” aesthetically to have a method call with to many parameters, and that we can’t just add parameters to methods whenever we need to pass another value. Touché. To this I responded that four parameters is not a big deal. Even though four parameter will not negatively affect a method signature, lets imagine that a method signature grew to 10 parameters, this can be solved by encapsulating all these parameters to one object. Programming languages such as Ruby use map literal for optional parameters and long parameter method signatures.

In the end, I won the debate but it didn’t feel like a victory. I doubted myself for pushing so strongly for what I know is right, in the end he was doing all the heavy lifting and this was just one small aspect of the feature as a whole. There is a line that if crossed you will be considered a micromanaging standard fascist, but that if you do not enforce you will inherit unmaintainable code. Coding standards goes beyond naming convention and third party libraries. There is a fine line, and you need to walk the line.

Google IO 2009: Mobile

TechKnow — Sun, 07 Jun 2009 05:31:57 +0000

I, like many 10-5 developers not working directly with ajaxified web 2.0 applications, was not able to go to the Google I/O conference. I don’t feel so bad not going since Google has just released video recordings of over 80+ technical presentations from Google I/0. Most of the technical presentations are pushing Google’s APIs such as Android, Google App Engine, GWT, and Open Social.

As an aid for myself, and maybe other GWT developers, I have organized the pertinent Android and mobile talks as follows…

Turbo-charge your UI: How to Make your Android UI Fast and Efficient
Learn practical tips, techniques and tricks for making your Android applications fast and responsive. This session will focus on optimizations recommended by the Android framework team to make the best use of the UI toolkit.

Supporting Multiple Devices with One Binary
The Android platform is designed to run on a wide variety of hardware configurations. Learn how to take advantage of the application framework to make your application run on a wide variety of devices without having to build a custom version for each.

Coding for Life — Battery Life, That Is
The three most important considerations for mobile applications are, in order: battery life, battery life, and battery life. After all, if the battery is dead, no one can use your application. In this session, Android engineer Jeffrey Sharkey will reveal the myriad ways — many unexpected — that your application can guzzle power and irritate users. You’ll learn about how networking affects battery life, the right and wrong ways to use Android-specific features such as wake locks, why you can’t assume that it’s okay to trade memory for time, and more.

A General-purpose Caching Architecture for Offline-capable Web Applications with HTML 5 Databases or Gears
Puzzled by all the new architectural choices possible when trying to build an offline-capable web application? So were we until we decided to design the newly launched Gmail Mobile Web for iPhone and Android’s offline capabilities by analogy with microprocessor caches: offline via a portable write-through caching layer running on either HTML 5 or Gears databases.

Mastering the Android Media Framework
Some monks might take a vow of silence, but Android certainly hasn’t. Attend this session, and help your app find its voice. Android engineer David Sparks will explore the multimedia capabilities of the Android platform, lifting the covers on the infrastructure to show you how it works and the right (and wrong!) ways to use it. You’ll learn how things work under the hood, how to dodge the common media-related developer pitfalls, and how to write secure and battery-efficient media code.

Lookup Pattern and Java Generics

TechKnow — Thu, 14 May 2009 14:34:52 +0000

In some situations I dislike the verbosity of declaring Java generics.

Map, List> m = getItemsMap();

But using Java generics reduces other forms of tedious class casting common when using List and Map objects. For example, in my current project their we use a Lookup pattern, used to locate concrete implementation to certain key services. For example, to read and write application data we use a FileService which we can get via the Lookup class.

FileService fs = (FileService)Lookup.lookup(FileService.class)

These services we lookup are stateless and we can switch the underlying implementation by modifying some configuration file. In terms of this discussion, I wanted to note that casting. Using Java generics that cast is not required if you use parameterized types. Notice that the key of the lookup is a Java type, in our application it is an interface which the underlying implementation class needs to implement. As you can imagine, the implmenation of the lookup method can be simplified to the following…

public static Object lookup(final Class type) {
    // compoments is a map of implementation service
    Object comp = components.get(type);
    return comp;
}

Using Java genetics we can use the class information in the parameter to cast the return type correctly. We can remove the required class cast by updating the code that locates the required concrete class for the service requested. Here is a simplified version of the lookup method which removes the need to cast.

public static  T lookup(final Class type) {
    T comp = (T)components.get(type);
    return comp;
}

Now, using this updated lookup method and employing Java generics our lookup can be of the following form.

FileService fs = Lookup.lookup(FileService.class);

Google App Engine for Java

TechKnow — Wed, 08 Apr 2009 17:47:38 +0000

Google App Engine was originally released, in Google beta, a year ago. Google App Engine originally had programming support for the Python programming language, but today, on the one year anniversary of its beta release Google has added Java support. Building Java support into Google App Engine means that they have built it for JRuby, Groovy, JavaScript, and all those languages that run on the JVM.

You can request access to Google App Engine for Java via this sign up. I am sure there will be a more news, documentation, and tutorials at Google I/O Developer Conference in May. In the mean time here are plenty of resources to get you started.

Google App Engine for Java

Java Web Service with HTTPS

TechKnow — Tue, 07 Apr 2009 22:51:18 +0000

I recently had to write a small Java client that calls out to a Java Web Service that was sitting behind HTTP over SSL (HTTPS). From what I could tell, they had an expired or self signed certificate because calling the Web Service would throw an nested SSLHandshakeException, ValidatorException, and SunCertPathBuilderException that read something like the following

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

After searching around I found a 2006 article from Andreas Sterbenz describing the solution to the unable to find valid certification problem I was encountering. The article went into to much detail as far as I am concern but it did provide the right solution.

The gist of the solution is to download and compile this Java class that saves the certificates from a particular domain to a file. This program will save a keystore with the certificates called jssecacerts in the local directory where you run the Java class.

This keystore needs to be used from the client application that is connecting to a SSL service. You can start the client Java process with the following Java system property: -Djavax.net.ssl.trustStore= … or you can replace the the cacerts file under jre\lib\security for the JVM you are using with the jssecacerts keystore file created from the aforementioned Java program.

Using the keystore file correctly should fix the unable to find valid certifiction exception.

Top Programmers on Twitter to Follow

TechKnow — Sun, 07 Dec 2008 05:57:32 +0000

Earlier this year I created a short list of top rubyist to follow on Twitter. At that time, that list was the first list of programming twitterers I had come across. Since then many other folks have created lists of programmers that are on twitter to follow. No matter how long the list of twitterers to follow is, you will always miss someone. So instead of coming up with yet another list of programmers to follow on twitter, I came up with a list of list of favorite .net, ruby, java, and technologist to follow on twitter.

If you like you can follow me too.

Silicon Valley Codecamp 2008

TechKnow — Sat, 15 Nov 2008 01:35:58 +0000

There was a large contingent of Microsoft evangelist at this years Silicon Valley Codecamp 2008 pushing Microsoft Azure, XNA, and Silverlight technologies. I was able to see Microsoft Surface in action. Surface is an interactive table top, it reminds me of a large iPhone made into a coffee table. Just like the iPhone, you gesture at the Surface screen to manipulate objects. Java, Groovy, and Flex also had a good showing. Below are conference notes from each of the sessions I was able to attend.

Microsoft Surface

Foothill College

Pizza Party

Technorati Tags: sv, codecamp, ms, azure, silverlight, xna, flex, flash, groovy, java, ria, javafx, ui, 3d, iphone

Component Based Java Web Development with Apache Wicket

TechKnow — Mon, 10 Nov 2008 07:45:30 +0000

Karthik Gurumurthy was at the Silicon Valley Codecamp 2008 to talk about Apache Wicket. Wicket is yet another Java based web framework. Wicket has a real nice separation between markup and code and consists of plain old java and plain old HTML. Unlike the other Java frameworks, Wicket has minimum configuration, zero XML files and no annotations. Even though Wicket is yet another Java based web development framework it does not introduce yet another expression language. Wicket templates are the most designer friendly web development view technology that I have seen, it essence they are pure HTML except for a wicket:id attribute that is added to tags for which you are interested in. The Wicket Java component for a HTML form has the same familiar feel as Swing. You first create a an instance of a Wicket page, then form object and add components to the HTML form elements such as text fields, password fields, etc, just as you would add JComponents to a JPanel.

Wicket is a relatively new framework compared with Struts, Grails, Spring MVC, Tapestry, GWT, WebWork, etc but it is getting traction. Currently there are three books dedicated to web development with Apache Wicket.

Technorati Tags: wicket, apache, webdev, java, html, component