Current Windows Internet Explorer versions do not support multiple class selectors in style sheets. This has been well known for a while; this article shows a technique I have used to work around this limitation.
Functions that take collection parameters should take the generic parameter. E.g. don’t do this:
public void process(ArrayList list);
This may seem obvious, but many JUnit tests are written that don’t really test anything useful.
Don’t write tests cases for code that’s too simple to fail on its own: that would be a waste of time. You’re supposed to write tests that test your application code, not the test framework or the compiler.
Import statements provide good documentation, but not if they contain wildcards. For example:
import com.zikzak.db.*;
import com.zikzak.util.*;
No function should ever throw a RuntimeException by design, unless it has documented requirements for its arguments or object state that are not fulfilled. Essentially, it must always be possible for the caller of a function to do enough checking so that it can be sure no RuntimeException will be thrown.
throws Exception or throws ThrowableUsing throws Throwable and throws Exception subverts the exception checking system. If you do this, callers are forced to catch Throwable or Exception, which may catch both unchecked and checked exceptions. This forces callers to use instanceof to see whether the exception is one that they can deal with.
Put TestCase classes in the same package as the class they are testing. This makes it easy to test protected and package-visible methods. It’s still a pain to test private methods though.
Profiling is an excellent way to find resource bottlenecks in a program. Java has built-in profiling tools that you can use to easily view a profile of a program’s runtime execution.
If a function that returns an object is unable to return the object because of an error, it should not return null. Instead, it should throw some defined exception. This means that the handling for the error can occur at the appropriate place, by catching the defined exception. This appropriate place may be at the [...]
Often in Java program stack trace, you will see some stack frames include a source line number, while some only say “compiled code”. This is because the stack frames without line numbers have been compiled by the JIT compiler, and the JIT compiler obliterates line number information when it compiles code.