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
Google Web Toolkit
Google have released the Google Web Toolkit — “Build AJAX apps in the Java language”. At first I thought this might just be their version of the Yahoo UI Library, but it turns out to be a completely different approach to the same problem. The YUI Library (and most other Ajax libraries) allow you to build a Web UI directly, using HTML and JavaScript. With GWT, you write a GUI application in Java, and GWT translates it into JavaScript and HTML for web deployment. It’s a less flexible approach, but could make it easier for Java developers to develop web applications with desktop-style GUIs — if this is what they really want. Continue reading “Google Web Toolkit” →
Use generic collection interfaces as parameters
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” →
Don’t write useless Junit tests
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.
Don’t import wildcards from non-standard Java packages
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” →
A RuntimeException is a programming error
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” →
Don’t use throws Exception or throws Throwable
Using 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. Continue reading “Don’t use throws Exception or throws Throwable” →
Junit tests: same package, different directory
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 a Java program easily
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” →
Throw exceptions: don’t return null
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” →