ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Why stop at JDK1.2? Only semi-serious question...
Date Mon, 15 Jul 2002 18:15:36 GMT

----- Original Message -----
From: "Jon Skeet" <>
To: "Ant Developers List" <>
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 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:   <>
For additional commands, e-mail: <>

View raw message