Maybe it's a hack, but surely no worse than: #ifdef RELEASE #define ASSERT(fact) #else #define ASSERT(fact) _assert(fact,_FILE_,_LINE _) #endif
As far as using BCEL, sure... But at install time or runtime? If at runtime, what's the overhead? And leaving the asserts in the bytecode doesn't enable them: One still needs -ea on the Java command line (or similar construct programmically), maybe restricting the assertions in actual Ant code (restricted to org.apache.tools.ant packages). --DD -----Original Message----- From: Jon Skeet [mailto:[EMAIL PROTECTED] Sent: Monday, July 15, 2002 11:40 AM To: Ant Developers List Subject: RE: Why stop at JDK1.2? Only semi-serious question... > You can still emulate this by wrapping all your assert's in an > > if (RELEASE) { > assert ...; > } > > with RELEASE a static final boolean... --DD Yeah, but that's just a horrible hack, IMO - and indeed in a lot of cases you *do* still want to be able to enable assertions where they're available, even in released kits. I'm investigating BCEL for the assertion stripping - it looks like it could actually be very simple. It may or may not be useful for Ant, but I'm sure I'll find a use for it at some stage :) Jon -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
