|
|
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 2 of 5
By default (that is, in the absence of the -source 1.4 switch), a J2SE 1.4 compiler does not allow assert statements. However, the compiler complains if the source code uses the assert keyword as an identifier or label. That means a J2SE 1.4 compiler rejects prior Java source files that use assert in this manner, even though the source compiled successfully under J2SE 1.3 or an earlier compiler. Note that this does not
affect previously compiled class files.
The following command compiles Foo.java:
javac -source 1.4 Foo.java
The resulting Foo.class file contains assertion code in the method m1(int). But, just as the compiler does not, by default, include the assertion facility, the java command does not, by default, enable assertions. In other words, assertions are disabled in the Java runtime environment
by default.
The default behavior of the compiler and runtime system seems backward to me. Assertions are an important enough addition
to the Java language that they should be included and enabled by default. The compile-line option should be -source 1.3 for the backward compatibility of not including the assertion facility, and the java command should enable assertions by default. I appreciate the pressure to preserve backward compatibility, but assertions
prove too important to be relegated to a special, nondefault case. But I'll get off my soapbox now and continue.
Command-line options to the java command allow enabling or disabling assertions down to the individual class level. The command-line switch -enableassertions, or -ea for short, enables assertions. The switch (I use the short form) has the following permissible forms:
-ea-ea:<class name>-ea:...-ea:<package name>...The first form enables assertions in all classes except system classes. A separate switch, -enablesystemsassertions, or -esa for short, enables system class assertions. System classes warrant a separate switch because developers rarely have occasion
to suspect assertion errors in the Java system libraries.
The second form turns on assertions for the named class only. The last two forms enable assertions at the package level. The third enables assertions for the default, or unnamed, package, and the fourth enables assertions for the specified package name.
Take care in using the second and fourth forms, since class and package names are not verified for existence. As we'll see
later in this article, the class ClassLoader maintains a mapping of class and package names to desired assertion status. When a ClassLoader subclass loads a class, the mappings determine the setting of a special assertions-enabled flag in each class. Any mappings
for nonexistent classes or packages are simply never accessed. In particular, the runtime system silently interprets a package
name without a trailing "..." as a class name.
Note that the syntax for enabling assertions at the package level uses ... rather than the expected *. The trailing ... serves as reminder of another assertion facility aspect: enabling assertions at the package level actually turns on assertions
for that package and all subpackages. For example, the command-line switch -ea:javax.swing... enables assertions for all Swing packages, and the command-line switch -ea:javax.xml... enables assertions for the five J2SE 1.4 XML packages. Interestingly, in the latter example the five XML packages are considered
javax.xml subpackages even though javax.xml is not, itself, a package.