Use Null Object instead of Null literals

Use Null Object instead of Null literals that reduce the extra overhead of checking whether the Object is created or not. Whenever you you want to access the object or access the properties of that object, you must have to check the object against the Null literals.

Sometime we heard that set some default value instead of null. There is no hard and fast rule for declaring all Objects with a default value.If we don't do then we have to take responsibility for exception NullPointerException.

So, I sugges to do Something for Nothing. This is not a new. If you go through the design patterns, you found that there is a Null Object Pattern. 

If a client calls a method on a field or variable that is null, an exception may be
raised, a system may crash, or similar problems may occur. To protect our systems from such unwanted behavior, we write checks to prevent null fields or
variables from being called and, if necessary, specify alternative behavior to
execute when nulls are encountered:
if (someObject != null)
  someObject.doSomething();
else
  performAlternativeBehavior();

Repeating such null logic in one or two places in a system isn’t a problem,
but repeating it in multiple places bloats a system with unnecessary code. Compared with code that is free of null logic, code that is full of it generally takes
longer to comprehend and requires more thinking about how to extend. Null
logic also fails to provide null protection for new code. So if new code is written
and programmers forget to include null logic for it, null errors can begin to
occur.

The Null Object pattern provides a solution to such problems. It removes
the need to check whether a field or variable is null by making it possible to
always call the field or variable safely. The trick is to assign the field or variable
to the right object at the right time. When a field or variable can be null, you
can make it refer to an instance of a Null Object, which provides do-nothing,
default, or harmless behavior. Later, the field or variable can be assigned to
something other than a Null Object. Until that happens, all invocations safely
route through the Null Object.

Kent Beck - father of eXtream Programming and JUnit and also contributor of Eclipse.suggested use of Null Object instead of Null literals.

Benefits and Liabilities

+ Prevents null errors without duplicating null logic.
+ Simplifies code by minimizing null tests.
– Complicates a design when a system needs few null tests.
– Can yield redundant null tests if programmers are unaware of a Null
Object implementation.
– Complicates maintenance. Null Objects that have a superclass must
override all newly inherited public methods.

Java Database Connectivity Key points

1. Use Type two driver for two tiered applications to communicate from java client to database that gives better performance than Type1 driver.
2. Use Type four driver for applet to database communication that is two tiered applications and three tiered applications when compared to other drivers.
3. Use Type one driver if you don't have a driver for your database. This is a rare situation because all major databases support drivers or you will get a driver from third party vendors.
4. Use Type three driver to communicate between client and proxy server ( weblogic, websphere etc) for three tiered applications that gives better performance when compared to Type 1 &2 drivers.
5. ass database specific properties like defaultPrefetch if your database supports any of them.
6. Get database connection from connection pool rather than getting it directly
7. Use batch transactions.
8. Choose right isolation level as per your requirement. TRANSACTION_READ_UNCOMMITED gives best performance for concurrent transaction based applications. TRANSACTION_NONE gives best performance for non-concurrent transaction based applications.
9. Your database server may not support all isolation levels, be aware of your database server features.
10. Use PreparedStatement when you execute the same statement more than once.
11. Use CallableStatement when you want result from multiple and complex statements for a single request.
12. Use batch update facility available in Statements.
13. Use batch retrieval facility available in Statements or ResultSet.
14. Set up proper direction for processing rows.
15. Use proper getXXX() methods.
16. Close ResultSet, Statement and Connection whenever you finish your work with them.
17. Write precise SQL queries.
18. Cache read-only and read-mostly tables data.
19. Fetch small amount of data iteratively rather than whole data at once when retrieving large amount of data like searching database etc.

Important guidlines for Java Programming

1. Never directly modify code generated by JAXB.
2. Generate JAXB into separate packages-don't commingle
3. Don't use generated JAXB classes as value objects in applications.
4. Do not close connection objects or issue commits, rollbacks, or savepoints within a DAO.
5. Database objects created within a method should be closed within the same method.
6. Always pass the database connection from the business logic layer.
7. Always specify a column list with an insert statement.
8. Always speicfy a column list with a select statement.
9. Use host variables in SQL statemnets instead of hard-coding literals in SQL strings.
10. code test cases for all DAO methods and put them in the test suite.
11. Any method that creates a database connection should close it in a finally block.
12. All exceptions thrown should implement.
13. Using stateless session beans improve performance.
14. Stateless session beans should avoid instance-level variables.
15. MDB's should not throw exceptions.
16. Acknowledge message receipt in a finally block.
17. Using native JDK exceptions before creating your own.
18. Exploit Java's unchecked exception capability.
19. Use native JDK exceptions before creating your own.
20. Limit the nesting depth of a try/catch block to two.
21. Don't catch exceptions and do nothing with them.
22. Never put a return statement in a finally block.
23. Avoid explicitly setting thread priority.
24. Explicitly name all created threads.
25. Identify all threads as daemon threads.
26. Log enough information on error so that you can reproduce an error sutuation in a single-threaded test case.
27. Explicitly name all created threads.