If you are interested in the Spring Framework’s MVC packages, this could be helpful. It’s a unified description of the life cycle of a web application or portlet request as handled by Spring Web MVC and Spring Portlet MVC. I created this for two reasons: I wanted a quick reference to the way Spring finds handlers for each stage of the request; and I wanted a unified view so I could see the similarities and differences between Web MVC and Portlet MVC. Continue reading “Spring MVC: How it works” →
Posts Tagged: Java
Functions that take collection parameters should take the generic parameter. E.g. don’t do this:
public void process(ArrayList list);
do this instead: Continue reading “Use generic collection interfaces as parameters” →
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.*; ...code... WidgetId = new WidgetId();
There’s no way to find out what package the
WidgetId class belongs to without searching through the source tree. Continue reading “Don’t import wildcards from non-standard Java packages” →
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. Continue reading “A RuntimeException is a programming error” →
throws Throwable and
throws Exception subverts the exception checking system. If you do this, callers are forced to catch
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. Continue reading “Don’t use
throws Exception or
throws Throwable” →
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.
Put TestCase files in a separate directory to the main source tree. This stops the source tree becoming cluttered with test classes, and also makes it easy to exclude them from your product release builds (since they don’t belong there). Continue reading “Junit tests: same package, different directory” →
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.
To generate a profiling report for a Java program, add the hprof profiler to the program’s command line as follows. Continue reading “Profiling a Java program easily” →
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 point of the function call, or somewhere further up the call stack. Continue reading “Throw exceptions: don’t return null” →