The Rational Programmer

Yeah, I understand. What's the big deal in defining constants in Java. But hold on, and spare me a few minutes. Read on. As a standard practice constants must be defined for values which do not change in the application. The use of string literals and numbers scattered across the code is discouraged. It is always a good practice to define constants for all of those values which is used at multiple places. Let’s first check the rules.  Final and Static  What makes a literal or a numeric value “ constant ”? Java provides for a keyword “ final ”. Anything that is final  cannot be changed once its value is set (in the context of a field). Thus any constant should be accompanied by the keyword “ final ”. The keyword “ static ” however is not mandatory to define a constant. A constant is something which is expected to be used outside the scope of the class, in most probability, would remain the same throughout the application. If that is the case, then the constant ...

Introduction Java 1.5 released a lot of features - notable among them were Annotation, Generics, Varargs, for-each loops and an ease-of-coding shortcut called 'Autoboxing'. Autoboxing is a way to automatically convert the primitive types to its corresponding 'Wrapper Classes'. The primary reason why we would like to convert the primitives to a wrapper class is a wrapper class' ability to hold null values. The primitives can never be null. Things were simple before Java 1.5 in the sense that when a programmer needed an object that can hold nulls as well, they would go for the wrapper classes and when they knew that it will always hold a value they would go for a primitive type declaration. One example for this is a bean class that holds a corresponding table value. Some of the values of a table row can be null. For those fields the value is declared as as a wrapper class for the database fields that will always hold a value we usually define them as primitives. ...