This applies the option to the Evaluator class and any of its nested types.
If you are using assertions in your code, the obvious thing you should do is always use ea with enough
specificity to get all your relevant code.
Multiple options are evaluated in order from the command line. Class-specific options take precedence over
package ones, and a more specific package option takes precedence over a less specific one. For example,
given
-da:com.acme.Plotter -ea:com.acme... -da:com.acme.products
-ea:com.acme.products.Rocket
assertions will be enabled for all classes and subpackages of com.acme, except the class
com.acme.Plotter, and disabled for all classes and subpackages of com.acme.products, except for
the class com.acme.products.Rocket.
The system classes are controlled separately because you are more likely to be searching for bugs in your code
than in the system code. To affect system classes, use the "system" variants of the options:
- enablesystemassertions/-esa and -disablesystemassertions/-dsa (the latter option is
primarily for symmetry).
The assertion status of a class is determined when that class is initializedsee "Preparing a Class for Use" on
page 441and never changes. This determination is made before any static initializers for the class are
executed, but after the initialization of the superclass. If a superclass static initializer causes a static method of
its own subclass to be executed, it is possible for that static method to execute before its own class is
initialized, and before the assertion status of that class has been determined. In such circumstances, the
execution of any assert statements must be dealt with as if assertions were enabled for the class.
12.10.3. Complete Removal
Even though assertions may never get executed at runtime, the code associated with them still exists, and they
can still consume virtual machine resources and add overhead to the performance of an application. For most
applications this isn't something you should worry aboutand a good just-in-time compiler will take care of the
overheadbut sometimes, in resource constrained environments, you do have to worry about it. The only way
to guarantee the complete removal of assertion related code is to edit the code and remove the assertions. But
there is a standard Java programming idiom that gives the source code compiler a hint that you don't want
certain sections of code present under some circumstances:
private static final boolean doAssert = true;
if (doAssert)
assert (cleared || size == origSize);
In the above code fragment, asserts will be checked only if the doAssert variable is true. The doAssert
variable is a compile-time constantit is static, final, and initialized with a constant valueand references to
compile-time constants are replaced, at compile time, with the value of that constant. If doAssert is false
nothing will ever cause the assert to get executed, so the if statement can be completely removed by the
compiler, if it chooses. You can also use this technique to elide debugging print statements, for example.