Exercises

1. Create a class containing a static clause that throws an exception if assertions are not enabled. Demonstrate that this test works correctly.
2. Modify the preceding exercise to use the approach in LoaderAssertions.java to turn on assertions instead of throwing an exception. Demonstrate that this works correctly.
3. In LoggingLevels.java, comment out the code that sets the severity level of the root logger handlers and verify that messages of level CONFIG and below are not reported.
4. Inherit from java.util.Logging.Level and define your own level with a value less than FINEST. Modify LoggingLevels.java to use your new level and show that messages at your level will not appear when the logging level is FINEST.
5. Associate a FileHandler with the root logger.
6. Modify the FileHandler so that it formats output to a simple text file.
7. Modify MultipleHandlers.java so that it generates output in plain text format instead of XML.
8. Modify LoggingLevels.java to set different logging levels for the handlers associated with the root logger.
9. Write a simple program that sets the root logger logging level based on a command-line argument.
10. Write an example using Formatters and Handlers to output a log file as HTML.
11. Write an example using Handlers and Filters to log messages with any severity level over INFO in one file and any severity level including and below INFO in other file. The files should be written in simple text. Modify log.prop to add an additional initialization class that initializes a custom Formatter for the logger com. Run JDB on SimpleDebugging.java, but do not give the command catch Exception. Show that it still catches the exception.
12. Add an uninitialized reference to SimpleDebugging.java (you’ll have to do it in a way that the compiler doesn’t catch the error!) and use JDB to track down the problem.
13. Perform the experiment described in the “Coverage Testing” section.
14. Create a doclet that displays identifiers that might not follow the Java naming convention by checking how capital letters are used for those identifiers.

[86] It is primarily oriented to static checking, however. There is an alternative system, called latent typing or dynamic typing or weak typing, in which the type of an object is still enforced, but it is enforced at run time, when the type is used, rather than at compile time. Writing code in such a language—Python (https://www.python.org) is an excellent example—gives the programmer much more flexibility and requires far less verbiage to satisfy the compiler, and yet still guarantees that objects are used properly. However, to a programmer convinced that strong, static type checking is the only sensible solution, latent typing is anathema and serious flame wars have resulted from comparisons between the two approaches. As someone who is always in pursuit of greater productivity, I have found the value of latent typing to be very compelling. In addition, the ability to think about the issues of latent typing help you, I believe, to solve problems that are difficult to think about in strong, statically typed languages.

^[87] Although the electronic version of this book is freely available, it is not open source.

^[88] The first try, anyway. I find that the process of building something for the first time eventually produces insights and new ideas.

^[89] Inspired by Python’s doctest module.

^[90] Originally placed in Thinking in Patterns (with Java) at www.BruceEckel.com. However, with the addition of the reflection approach in JUnit, my framework doesn’t make much sense anymore and will probably be removed.

^[91] A key phrase from Extreme Programming (XP). Ironically, one of the JUnit authors (Kent Beck) is also the author of Extreme Programming Explained (Addison-Wesley 2000) and a main proponent of XP.

^[92] Bill Venners and I have discussed this at some length, and we haven’t been able to figure out why it is done this way rather than creating each object right before the test is run. It is likely that it is simply an artifact of the way JUnit was originally implemented.

^[93] Design by contract is described in detail in Chapter 11 of Object-Oriented Software Construction, 2^nd Edition, by Bertrand Meyer, Prentice Hall 1997.

^[94] Except by the occasional company which, for reasons beyond comprehension, is still convinced that closed-source tools are somehow better or have superior tech support. The only situations where I’ve seen this to be true are when tools have a very small user base, but even then it would be safer to hire consultants to modify open-source tools, and thus leverage prior work and guarantee that the work you pay for won’t become unavailable to you (and also make it more likely that you’ll find other consultants already up to speed on the program).

^[95] This is not available on the web site because it’s too customized to be generally useful.

^[96] Other tools are under development, that attempt to repair the problems with make without making Ant’s compromises. See, for example, www.a-a-p.org or search the Web for “bjam.”

^[97] Cron is a program that was developed under Unix to run programs at specified times. However, it is also available in free versions under Windows, and as a Windows NT/2000 service: https://www.kalab.com/freeware/cron/cron.htm.

^[98] A pluggable algorithm. Strategies allow you to easily change one part of a solution while leaving the rest unchanged. They are often used (as in this case) as ways to allow the client programmer to provide a portion of the code needed to solve a particular problem. For more details, see Thinking in Patterns (with Java) at www.BruceEckel.com.

^[99] A term coined by Bill Venners. This may or may not be a design pattern.

^[100] This is the Observer design pattern (ibid).

^[101] I learned C++ primarily by printing information, since at the time I was learning there were no debuggers available.