It sure sucks not having an integrated preprocessor. Without one, every new Java language innovation is virtually guaranteed to break backwards compatibility, or at least make debugging a nightmare if you try to incorporate preprocessing to make use of such innovations.
JavaSoft continues to hold the line that preprocessing isn't necessary, but within every project I look, there is inevitably a hack in place to deal with asserts, log statements, and/or backwards incompatible APIs (such as in JDBC). Doesn't it ever make you wonder if all this hacking is going on, a more general solution would be better? I recently wrote an ant task, I call it <ppjavac>, which preprocesses java source using Velocity. The result is then spit out into a temp directory which then gets compiled using traditional <javac>. <ppjavac> is a 'drop-in' replacement for <javac> so it can be used by simply substituting <ppjavac> wherever <javac> was used. Then you can sprinkle VTL wherever needed. However, there are at least three major issues that typically arise when using an IDE to develop and/or debug Java code with preprocessing directives: 1. Preprocessing directives are not understood by IDEs. When debugging, you must debug against the preprocessed output, not the original source. 2. Attention must be paid so that changes are made to the source and not the preprocessed output. IDEs do not help you with this. 3. Ant must always be used to perform builds since Java IDEs don't typcially have preprocessors. So, do I use preprocessing to conditionally compile assert and log statements? If backwards compatibility is important, I simply don't use bacwards incompatible APIs or language features. As for log statements, I live with the overhead. Where I use preprocessing most is to deal with backwards incompatible APIs, such as in JDBC, for which there is simply no alternative common API (even a deprecated one) for getting the job done. If anyone is interested in <ppjavac>, I will happily make source available. didge > -----Original Message----- > From: Beton, Richard [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 26, 2002 3:31 AM > To: [EMAIL PROTECTED] > Subject: How to strip 'assert' statements > > > Hi all, > > I have been seeking a way to remove assert statements from source code > (... a copy of the source code, of course ...) so that I can compile > JVM1.1 compatible class files. The JDK1.4 compiler will only generate > JVM1.1 class files from source code without assert statements, alas. So > I've been thinking about how this might be done using Ant. > > Is there a way to do this already, or do I need to write a task (a > MatchingTask) that operates like 'copy', albeit with the additional > function of stripping asserts? > > A related but different activity that I'm interested in is to remove > Log4J debugging from my code using some Ant task. [There is some debate > about leaving the Log4J in place, vs removing it. Without entering that > debate, suffice it to say there may be some (rare) instances where it > helps to remove the Log4J code.] Is there a known way to do this, or is > this something else I might need to develop? > > Regards, > Rick > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, > Bracknell, Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is > confidential to > Roke Manor Research Ltd and must not be passed to any third party without > permission. This communication is for information only and shall > not create or > change any contractual relationship. > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
