Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

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

JavaWorld.com > Java Standard Edition >

Letters to the Editor

What's the difference between Jxta and Jini? Find out in this month's letters.

JavaWorld.com, 11/29/01

  • Print
  • Feedback

'J2SE 1.4 premieres Java's assertion capabilities, Part 1'
Wm. Paul Rogers

Reason for -source 1.4 is obvious



Paul,

Your soapbox comments regarding the need for -source 1.4 were completely unnecessary. It's obvious that the reason it exists is so existing make files and other Java compilers don't break because people created their own assertive methods. I'm surprised that you would overlook this.

Jerry Fontaine

Jerry, I didn't necessarily overlook your point. I state that I "appreciate the pressure to preserve backward compatibility," but believe assertions are "too important to be relegated to a special, nondefault case." If you want to compile 1.3 code, you can use either a 1.3 or a 1.4 compiler. You needn't change any of your build scripts to compile 1.3 code with a 1.3 compiler. If you choose the 1.4 compiler, I'm simply stating that you should be in the position of supplying a -source 1.3 switch. Note Sun's warning: "support for 1.3 source compatibility is likely to be phased out over time." I'm not sure how they will handle the command-line switches at that time, but I'm guessing the -source 1.4 will no longer prove necessary. I don't know what that means for your build scripts. And maybe, like a distant Y2K issue to a 1991 COBOL programmer, you believe that to be too far in the future to draw any attention. Nevertheless, I don't believe your reason will be quite so "obvious" in a few years. And I certainly do believe that assertions are more important than preserving the forward compatibility of build scripts. Wm. Paul Rogers


Do you need to know during compile time if a class is assert-enabled?



Paul,

Regarding the "abusive" idiom:

boolean assertionsEnabled = false;
assert assertionsEnabled = true;


I fail to see how it works, since at compile time you have only the -source 1.4 switch to play with, and only in runtime would you have the class-specific assert switches. In contrast, for this idiom to work as expected, you'd need to know during compile time if the class is assert-enabled or not. That means you'd get more code than needed if you switch on the -source 1.4, but later activate one class for assertion in the VM. The extra code would be for the asserts of all other classes as well.

Personally, I find the class-specific asserts odd. For me, coming from the C++ world, either you are in DEBUG or RELEASE mode. Being in DEBUG mode just for one class seems strange.

Roy Tal

Roy, You could not compile code using the idiom without the -source 1.4 switch since it includes an assert statement. But you do not need to know the status of any class assertion flags at compile time for the code to compile. In fact, you can't know. Assertion status is maintained in the Class object, and there are no objects at compile time. At runtime, the statement boolean assertionsEnabled = false; always executes. The statement assert assertionsEnabled = true; executes only if assertions are enabled. So the variable assertionsEnabled does indeed reflect the assertion status for the class from which the object in question was instantiated. As for assertions and a dichotomy between DEBUG and RELEASE, that is an unfortunate aspect of Java's adoption of assertions, not a reflection on the general utility of the concept. Assertions are the bedrock of Design By Contract (DBC), and DBC is far from a simple DEBUG/RELEASE mode indicator. I wish the Java assertion facility looked more like DBC and less like the weakened C++ macro version of assertions. Wm. Paul Rogers


Should you enable assertions in a production system?

  • Print
  • Feedback

Resources