ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurie Harper <>
Subject Re: preprocessing java source
Date Mon, 09 Sep 2002 05:55:13 GMT
Re-read your list of downsides; these are all good reasons why Java doesn't
include a pre-processor.

Have you considered factoring out the JDK version dependent code and using
reflection to select the appropriate implementation at run-time? That way,
you eliminate the need for pre-processing to comile on any platform and, as
a bonus, you get to run on any platform -- not just the one you compiled on.

That's the way to deal with platform dependencies in an object oriented


On 9/6/02 8:05 PM, "didge" <> wrote:

> Folks,
> For some time I've been looking around for a solution to the problem of
> handling multiple JDK platforms.  In C/C++, I would have relied on the
> preprocessor and it would be a done deal.  No such luck in Java.
> However, I realized that by combining Ant and Velocity, I could come up with
> a workaround that might meet my needs.  I'm offering my solution to the this
> group for possible inclusion as an optional ant task, if you feel that it is
> generally useful as I think that it is.
> Essentially, I subclassed the Javac ant task, and used Velocity to
> preprocess each file as if they were template files. Then, I let Javac
> continue to compile just the preprocessed files.
> The net effect is that source files become Velocity templates and you can
> now use VTL to do as you please with your source.  And, as an added bonus,
> the VTL in the source files can access all of the properties known by Ant.
> I simply put the into the VelocityContext supplied to the
> merge().  For example, you can get access to an ant property called foo by
> using this VTL:
> #if ( $ant.get("").startsWith("1.4") )
> some code...
> #else ( $ant.get("").startsWith("1.3") )
> other code
> #else
> default code
> #end
> It is also possible to comment out the preprocessor directives so that IDEs
> won't choke on the VTL directives.  Since Velocity ignores Java comments,
> Velocity will process its directives regardless, but this can result in some
> rather wierd situations for IDEs, as you can imagine, since you could end up
> with a strange mix of code.  Non realtime parsing IDEs probably won't care
> but those that do, such as IDEA, will markup the code with lots of syntax
> errors.  But this should work very well at least for assert like statements.
> On the bummer side, you must use ant to build effectively.  This is
> mitigated a bit by the fact that most IDEs now let you execute your ant
> targets directly, but you have to be smart about debugging.  You can no
> longer debug against the original source, you now have to go against the
> source in the temporary directory, unless your java-commented VTL is very
> carefully written.
> An additional bummer is for javadoc comments that reference set methods.
> They usually look like someclass#setFoo, which Velocity interprets as a
> directive.  But by simply escaping the #, e.g. someclass\#setFoo, all will
> be well.
> I've successfully used this now to write a complete java.sql wrapper library
> that compiles from version 1.1.x through 1.4.x from a single source.
> I'd be interested to know whay you think, if any of you have any time to
> look at it.  See the attached .zip.
> To build, you'll need to copy ant.jar (1.4.1 is what I used) and
> velocity-dep-1.3.1-rc2.jar.  (I didn't include them with the zip because
> they're large and you may not want to bother).  Unzip the .zip and copy the
> aforementioned .jars into the lib directory and exectue 'ant build-g'.  To
> see an example, execute 'ant ppjavac' which will preprocess and compile a
> file under the example directory called  You'll get a
> sub-directory called 'foo' where the processed file will end up.  It's
> .class will go into build/classes.
> The interesting ant target in the build.xml is called ppjavac.  It takes all
> of javac's attributes and adds two more.  preprocess allows you to turn on
> or off preprocessing.  prepDir is the location of the temporary directory.
> enjoy!
> didge
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message