> BTW, I have just noticed the new "annotations processing tool" (apt)
> which is a utility supplied with the 1.5 JDK. I'm not (yet) clear on
> what it actually /does/, but then I'm not clear on what the OP /wants/
> to do, so it's clearly the right tool for this job ;-)
A little more info.
I'm writing JUnit tests, following the usual practice of creating a
seperate source tree, with identical package names. However, I also
want to test some private stuff. (Yes, I know the arguments against
this; let's not rehash them.)
Rather than use reflection, I have created a nested class with package
accessible methods, which can be called by the unit tests. I have
created an annotation (@TestCode) and applied it to this class. Now I
want to create an Ant task to move all class files with the @TestCode
annotation from the ${PROJECT}/bin tree to ${PROJECT}/test/bin.
From what I can tell of apt, it processes source files, not compiled
classes. It might be possible to use apt to control the build itself,
and put any @TestCode classes into the test/bin tree, but it seems like
more work than it's worth.
I've looked at BCEL; it doesn't support annotations at all. ASM does,
but I really want to avoid adding a dependency on an external library
for something so trivial. At this point, I think I'm just going to
munge the file name into a class name and use Class.forName, etc.
I don't suppose the string munging code is accessible somewhere in the
JDK?
Thanks!

Signature
========================================================================
Ian Pilcher i.pilcher@comcast.net
========================================================================
Chris Uppal - 24 Jan 2006 15:42 GMT
> I don't suppose the string munging code is accessible somewhere in the
> JDK?
I don't think so.
> Rather than use reflection, I have created a nested class with package
> accessible methods, which can be called by the unit tests. I have
> created an annotation (@TestCode) and applied it to this class. Now I
> want to create an Ant task to move all class files with the @TestCode
> annotation from the ${PROJECT}/bin tree to ${PROJECT}/test/bin.
I may be missing something, but wouldn't it be simpler to skip annotations
altogether and always name your nested "backdoor access" classes something like
BackdoorAccessForTests ? Then you could identify the corresponding .class
files easily with any tool.
-- chris
Ian Pilcher - 24 Jan 2006 15:48 GMT
> I may be missing something, but wouldn't it be simpler to skip annotations
> altogether and always name your nested "backdoor access" classes something like
> BackdoorAccessForTests ? Then you could identify the corresponding .class
> files easily with any tool.
Funny, that's what I originally did, and I suppose that nothing prevents
me from going back. An annotation sure seems like the "right way to do
this" (TM).
I must admit, I thought that apt would be able to handle this when I
originally started. I should have learned from the @SuppressWarnings
fiasco.

Signature
========================================================================
Ian Pilcher i.pilcher@comcast.net
========================================================================