[jdt-dev] [how to?] Preprocess .java files before they are passes to the

[Matt Quail <spud-list@xxxxxxxxxxx>]

Hi all,

I was wondering if anyone has any tips or pointers on the following 
problem. (Is this the right mailing list?)

I am writing an Eclipse plugin that needs to "preprocess" .java files 
before they are compiled by the JDT builder.

As an example of why someone would want to do this, take the iContract tool 
( http://www.reliable-systems.com/tools/iContract/iContract.htm ). It 
preprocesses .java files, looks at special javadoc comments, and inserts 
pre/post conditions into your code. There also seems to be a VisualAge for 
Java plugin for iContact ( http://www.reliable- 
systems.com/tools/iContract/IDEs/VAJ/VAJ.htm ).

So, I am wanting to do a similar thing in Eclipse (not an iContract plugin, 
something else).

In an ideal world, this would be easy if you could install a "builder 
plugin", that was passed an InputStream for each .java file, and returned 
an InputStream that represented the processed .java file. That would be my 
*ideal* mechanism, but I know it doesn't work that way in JDT.

I have partial implementations of the following two techniques I'm trying. 
But before I work on them some more, I was wondering if anyone has any 
recomendations. Or is the current JDT builder not really designed to 
support this.

Preprocess trick 1:
a) Install a custom Builder as the first builder in the project.
b) It's job is to pre-process the .java files, and copy them to some 
temporary source directories.
c) These source directories are added as source-paths to the IJavaProject.
d) The "real" source directories are hidden (I'm just setting a very 
liberal "exclude" at the moment).
e) The JDT builder picks up my .java files before the "real" .java files, 
and compiles the preprocessed versions instead.


This solution is clunky... you have these temporary source files appearing 
in your project, etc.


Preprocess trick 2:
a) "swizzel" all the "source" IClassPathEntry objects in the project (while 
the JDT builder is running)

This involves removing the existing IClassPathEntry objects, and replacing 
them with my own subclass of IClassPathEntry. My subclass delegates to the 
existing objects, but does a little "path munging" to point to the real 
entries.

This trick actually isn't working too well. In addition, it is documented 
that clients shouldn't subclass IClassPathEntry themselves (since all the 
elementEncode/Decode stuff in the ClasspathEntry concrete subclass is kinda 
important ;D )

So, any ideas? My other solution is to cut-and-paste 
org.eclipse.jdt.internal.core.builder.JavaBuilder into my own builder, and 
implement the filtering directly (I would probably then have a different 
cut-and-pasted builder for each version of Eclipse... yuck).


Thanks for your time,

=Matt