Perhaps first you should choose a documented formatting standard and follow its rules. For example Elements of Java Style.
Otherwise, I would suggest throwing the code into an IDE like Eclipse and choosing Source->Format. After you find out what that looks like, you can then tweak Eclipse's code formatter to produce the results you would like to have.
I guess there are other pretty-printers that would also do the job for you.
To do it manually you can set your tab width to 4 spaces and a wrap indention to be 8 spaces. String literals have to be broken by hand into pieces and concatenated with the + operator. The compiler joins the pieces up at compile time.
A second spent formatting code is a second wasted. There are tools that will automatically format your code and many of them run from the command line if you have no interest in an software development console commonly known as an IDE � integrated development environment.
Use your editor/IDE to format the code for you. Use a battle-tested format rather than presume that some how you know better than what the industry is using. Without question, the worst programmers I know also have this habit of "cleaning up" code to fit a bizarre non-standard style.
Your employer won't like paying to do something that has been automated for probably 30 years now.
P.S. Your code looks excellent as shown. [ September 17, 2005: Message edited by: Rick O'Shay ]
They don't need to be as per the rules of a compileable source code unit, but they mey need to be in accordance perhaps with some other fundamentals. That is, if your public contract may throw a NullPointerException, you should let your clients know (shouldn't you?), and by declaring it with a 'throws' clause allows this information to be available through reflection. In fact, all public contract operations (interface methods) that accept one or more reference type parameters should (at least mine do) declare to throw NullPointerException; the optimal, but not very nice, workaround to the flawed existence of 'null' i.e. fail as early as possible.
Alternatively, if you don't wish to encourage the bind from your API to the language (and particularly its flaws), use an annotation; although unconventional, you get all the benefits otherwise.