Tag Archives: Java/Java EE

The Joy of Null

Posted on by
8

Often in the database world, you do not have all the information needed to create a record. For example, you may have a person’s full name but not their middle name or initial, or you might be missing their date of birth. In such cases, the recommended solution is to fill that field with a special database value referred to as Null. Over the years and for a variety of reasons, I have noticed some database designers and software developers have invented their own equivalent of Null. This article is about how this came about and why the practice should be discontinued.

I’m inventing a new term today called null-equivalent value. A null-equivalent value is a value in a system that is not actually null, but meant to imply null. The most common null-equivalent value is a blank string.

Null

Part 1: What happened to null?

Oftentimes, database designers will (perhaps incorrectly) mark a column as “Not Null”, which translates to: this field is absolutely required for all records and we forbid anyone from inserting a record without this value populated. Some time later, software developers will then build an application on top of the database and realize they are missing some of the ‘required’ information needed to create a record. At this point the developer has one of three choices:

  • 1. Acquire the missing information before inserting the record
  • 2. Modify the database design to remove the “Not Null” attribute on the field
  • 3. Insert a null-equivalent value such as a blank string

Clearly, #1 is the best solution since it was the intention of the database designer that this field be populated, but, as I alluded to, that decision may have been incorrect. It may be that the field is not required, and creating records without this field make sense within the data model. In that case, the developer should consult a database designer and go with solution #2 – to remove the “not null” attribute from the record. Often, though, developers are prohibited from making changes to the database and the process of updating the database is long, vast, and sometimes risky. So the vast majority of developers will go with the ‘quick fix’ of #3, and insert a null-equivalent value since it’s the least work in the short term.

While this is the most common reason null-equivalent values are inserted into the database, it’s by far not the only reason. The second driving force results from a poor mix between the presentation layer and data layer. Assume a developer has the freedom to insert null values into a column, ie, the column is nullable. They may choose to instead insert a null-equivalent value such as a blank strings for a variety of reasons. For example, if a developer outputs the contents of the database directly to the screen, they often prefer to use empty strings rather than nulls since it’s a much more lazy approach – they do not need to convert the null values to empty strings, and can display them directly.

I’ve mentioned two of the main driving forces for null-equivalent values, but there others. I use the term null-equivalent instead of blank strings because developers will sometimes insert “special values” meant to imply null as well as have a secondary meaning such as “Lost Data”, “Missing”, or, in one case, “Null” (yes, these are real examples). In many of these cases, the data model should have been updated to include a boolean column, such as “Lost Data = true”, to explain the reason why the original field is blank. But many developers are nothing if not lazy, and the time required to make a database change, as I mentioned, is great. So, they will overload a column with a special single value, used to imply multiple values, all of which should have been fleshed out in a better database design.

The next article will continue this discussion and consider reasons why null-equivalent values are harmful to the database. In other words: TO BE CONTINUED.

Why JDBC + JSP = Bad

Posted on by
10

Over years of moderating at The JavaRanch, I’ve seen one type of question spring up on a weekly basis: that asked by people who need help with JDBC code inside of Java Server Pages (JSPs). As much as we may want to help this individual fix their particular problem, the overriding thought of “STOP WHAT YOU’RE DOING” often prevents us from doing so. The purpose of this post is to explain why putting JDBC code inside a JSP file is akin to shooting yourself in the foot. With a shotgun. While not wearing shoes.

Don't use JDBC inside of JSP pages

1. You cannot reuse the code
First and foremost is the issue of code reusability. While importing java classes is quite common, importing code from a JSP is not. While you can write JSP functions, although I never recommend doing so for reasons I won’t get into now, you’re basically writing code that you cannot be used anywhere else, particularly in non-JSP java classes. The most common counter response to this is “Well, I don’t need to use it anywhere else”. Yes, you do. Whether its just reusing code for making the connection to database or the code for performing a query and reading the results, it will be used again at some point in the future in a way you have not thought of yet. Unless you are being paid by the line and prefer this sort of thing, it’s a bad move, and I guarantee your code base will be much larger than someone who put all their JDBC code into normal Java classes. Larger code base means more difficulty to maintain and more headaches for you down the road.

2. You are mixing business logic with the presentation layer
Probably the most overlooked issue for inexperienced developers is the fact that you’re mixing the business/data layers with the presentation layer. I’ll put it another way, if your boss comes in one morning and says we’re throwing out the JSP front end and replacing it with a web service, Java Swing, Flash, or some other interface, there is virtually no way for you to reuse the database code without going through every line of every JSP file by hand. If the database code had been placed in plain java files, then you would have a path for packaging the JDBC code into a single JAR and making it available as a service to a different front-end client such as a web service, Flash, etc.

In enterprise development, the presentation JSP layer and the database are often separated by multiple layers of indirection such as described by the commonly used three-tier architecture pattern. Those who are just starting out programming often do not know why mixing these layers is bad, but I promise you if you stay with software development you’ll understand one day.

3. But it’s just this once!
Often times, JDBC code enters JSPs by developer lying to themselves saying “Well, it’s just this once” or “I just need to test something”. Instead of being removed when the developer is done ‘testing’, the code often persists for a long time afterward. Furthermore, putting your JDBC code inside of reusable Java classes makes testing go faster! Spending 10 minutes setting up a single reusable Java JDBC class will save you hours down the road. Then, if you want to test more than one JSP page with JDBC logic, you already have your Java class file to start with. Proponents of test-driven development tend to understand this better than anyone.

4. It’s really hard to maintain
Code maintenance is another topic that new developers do not fully appreciate since they have not spent years maintaining the same code base. Unless you write the most beautiful JDBC code imaginable, its very difficult to read through huge JSP files looking for bugs and/or making enhancements. It’s a lot easier if all the JDBC access is restricted to a set of files much smaller in size than the JSP code base.

5. It’s a really bad practice
If after reading this article you still do not fully understand why you should not put JDBC code inside of JSPs, let me simplify the issue by saying “Just Don’t Do It”. Whether or not developers understand the reasons against doing so is not as important as stopping them from doing so in the first place. In short, you create code someone else (possibly yourself) will have the misfortune of maintaining down the road.

Never return Null Arrays!

Posted on by
7

Continuing on Jeanne’s theme of nulls, its a pet peeve of mine when I come across code that returns null arrays instead of empty arrays. The purpose of this post is to discuss some of the reasons why its a good practice to return empty arrays over null arrays, including Collection objects or typed array.

Null Pointer Exception

Consider the reusability of the following code:

public List getItems() {
   ...
   // There are no items, return null
   return null;
}

Let’s say you want to iterate on the results, the following code would throw a NullPointerException if used in conjunction with the code above:

List items = getItems();
for(int i=0; i<items.size(); i++) {
   // If there are no items, this code will throw a null pointer
}

Iterating on an array is one of the most commons practices in Java, so returning null instead of an empty array means the person is going to have to do extra null checks when they really don’t need to. In this situation, an empty array would suffice and would not produce any errors.

To summarize, it makes the code shorter, easier to read, and less likely to throw a NullPointerException. Also, there is some confusion with returning null since you may (or may not) be saying an empty array is the same thing as null. For example, the following would be confusing logic:

List items = getItems();
if(items == null) {
   // If null do one thing
} else if(items.size==0) {
   // If empty do another?
}

In this situation its not clear why you might act differently on the two return values and this can lead to confusing, ambiguous code.

The only time I might consider returning null valid is if there was an error of some kind, but then you should be throwing an exception (something more programmers are hesitant to do). Think of it like this, would you rather read a stack trace with a detailed error what went wrong in the code created by you, or would you rather see NullPointerException and wonder what of a dozen objects might have been null?