----- Original Message ----- From: "Jon Skeet" <[EMAIL PROTECTED]> To: "Ant Developers List" <[EMAIL PROTECTED]> Sent: Monday, July 15, 2002 10:31 AM Subject: RE: Why stop at JDK1.2? Only semi-serious question...
> >Maybe it's a hack, but surely no worse than: > > >#ifdef RELEASE > >#define ASSERT(fact) > >#else > >#define ASSERT(fact) _assert(fact,_FILE_,_LINE _) >> #endif >No, no worse than that - but that's bad enough. actually, both have a flaw in that if you have accidentally put side effecting code in your assertion, it doesnt get run in non-debug builds. In C++ step one to tracking down differences between release and debug builds was to decouple optimizer bugs from #ifdef RELEASE behaviour by doing an optimised build with DEBUG defined, and a debug build with RELEASE defined, and then look at what worked. > As far as using BCEL, sure... But at install time or runtime? > If at runtime, what's the overhead? Once per class loading. I would imagine it'll be hard to even detect, unless BCEL's slower than I'd guess. > >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). >Sure - but it means you *can* enable them without recompiling, which is the important thing as far as I'm >concerned. Does anyone know if you can turn asserts on on the fly or not? I think the programmatic interface would let you do that; with a JMX wrapper you could manage assertions on a running system. That would be slick. Mind you, I need a way of doing that for log4j too. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
