Page 3 of 6
Since the 1.4 compiler is essentially identical to the generic compiler, you shouldn't have to recompile the code that uses the libraries. The resulting classes should be identical with either compiler. You might try a binary diff, to be sure. If you're the adventurous type, you can try creating a totally generic version of your library classes and compile that. The generic compiler can then type-check the implementation for consistency.
However, keep in mind that generic classes produced by the generic compiler have not been subjected to the same rigorous testing as classfiles produced by the production compiler. As a result, they could still harbor errors; treat this process as an experiment in progress.Do it for a stable library that won't be seeing much change and see how the classes run. If they perform, great; if not, drop back to the production compiler, report the bug, and wait for a new version of the generic compiler.
Unlike generics, assertions are ready in Java 1.4. Assertions, according to Sun's Joshua Bloch, are "statements the programmer
believes to be true" at any given point in the program. The assertion facility adds a new keyword to the language, assert, which captures those assumptions.
Adding assertions to a program documents what you believe to be true, making your assumptions clear to others. More importantly, assertion statements let the runtime engine (the VM) verifyyour assumptions.
The basic syntax for an assert statement is:
assert expression ;
Assertions speed up debugging because they immediately identify the differences between your expectations and reality. You don't have to backtrack from the point of the error to identify the cause.
You can also add information to the message generated when an assertion fails, like this:
assert expression : data ;
For example, if an index's value is calculated from some base value, then the following statement would validate the index and also indicate the value that caused the problem:
assert index > 0 : baseValue ;
To enable assertions, you compile with the -source 1.4 switch, which is necessary for backward compatibility. It alerts the compiler that assert is a reserved keyword. Without it, a class is free to use the word assertfor a variable or method name. (However, going forward, that is clearly not a good idea!)
Assertions are then compiled into the classfiles and enabled at runtime with the -ea (enable asserts) switch (for assertions in your code) or the -esa (enable system asserts) switch (for assertions in the runtime libraries). Or you can use both switches for the maximum runtime
checking of assumptions.
The great news is that you can enable assertions in the field. You'll test with them enabled, of course, to speed the debugging process. And for maximum speed, normal production runs will disable the assertions. But when something goes wrong, you can enable them with a runtime switch to help isolate the error.
Bloch advised that you monitor your internal dialogue to write assertions. Every time you think to yourself, "At this point, I know that..." or write a comment to that effect, capture that assumption with an assertion. He mentioned four cases where asserts are particularly helpful: