|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 4 of 5
tmp.sub.Derived.
tmp.sub.
tmp.sub.
This level of implementation detail demystifies the determination of class assertion status and explains several previously made comments:
ClassLoader.
ClassLoader are simply being overwritten.
As a final note on the implementation detail, ClassLoader subclasses set a class's assertion-status flag when loading the class. Adding or modifying class or package name mappings
using ClassLoader methods does not affect already loaded classes. For example, suppose myClassLoader loads class tmp.sub.Derived, no class- or package-specific mappings exist, and the default assertion status is false. A programmatic call to myClassLoader.setClassAssertionStatus("tmp.sub.Derived",true) does not enable assertion in the already loaded class tmp.sub.Derived. If myClassLoader later reloads that class, then the assertion status will reflect the programmatic change. Fortunately, this is only of concern
for programmatic changes and does not affect the more common usage of setting assertion statuses using command-line switches.
The assertion facility does not provide a direct means of conditionally preventing the inclusion of assertion code in a class file. Section 14.20 of The Java Language Specification, however, provides a standard idiom for achieving conditional compilation in Java. Applied to assertions, the idiom looks something like this:
static final boolean assertionsEnabled = <true | false>; if( assertionsEnabled ) assert expression1;
Since the variable assertionsEnabled is static final, when the value is false, a compiler can detect that the assert statement is unreachable and can remove the assert statement code.
The assertion facility also does not provide a means of querying the assertion-status flag in a class. As a slight abuse to
the assertion facility, however, the following idiom sets variable assertionsEnabled to the current class assertion status:
boolean assertionsEnabled = false; assert assertionsEnabled = true;
This idiom abuses the assertion facility by using an assertion to achieve a desired side effect. Expressions within an assert statement should not produce side effects, since doing so exposes program execution to potentially different behavior with
and without assertions enabled. You should use assertions to produce more reliable programs, not less reliable ones.
Finally, caution must guide the development of the expressions used in assert statements. In addition to not producing side effects, assertions should not alter normal program execution. As a pathological
example, the following class enters an infinite recursion when assertions are enabled and only stops when a StackOverflowError brings the program to a crashing halt: