| code generation using annotation processor framework [message #250241] |
Mon, 17 December 2007 13:17  |
Eclipse User |
|
|
|
In the aptDemo sample , we can generate a new Class based on annotation
into the default folder ".apt_generated" under the current project.
questions:
1.How can we generate into a different project and folder instead of the
default ".apt_generated"?
2.Is there also a way to "not generate a new class" but to generate
addtional code/method bodies etc.. into the current file based on the
annotations in it ?
3.Can annotation processor and xdoctets coexists in the same file? or if
we enable the annotation processor, the xdoclets processor will be
disabled ?
|
|
|
|
|
|
|
| Re: code generation using annotation processor framework [message #250278 is a reply to message #250274] |
Tue, 18 December 2007 19:32  |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Ivy" <ivyho@ca.ibm.com> wrote in message
news:1ba695a88b6768a6961be8df8cda87f8$1@www.eclipse.org...
> Our usage pattern : we generate xdoclets defined in our source which has
> skeleton methods defined and the xdcolets will invoke the code-generator
> to generate method bodies into the source. (using WRD)
>
> Now we want to replace the sdcolets with annotations and use the apt
> processor to perform codegeneration.
> If we cannot regenerate code into the source, we may have problems.
> What is the reason why it is not allowed ? No way to by-pass this
> restriction?
An annotation processor definitely cannot generate code into its own class.
There is no way to bypass that restriction.
I can't claim to speak for the various expert committees that worked on the
annotation processing specs in Java 5 and Java 6, nor for the original
decision that the Java language should not include a macro preprocessor
(that being essentially what you're trying to recreate). However, let me
suggest some of my own reasons not to do what you're trying to do.
Consider, first, that there are three possible approaches to generating code
directly into the annotated class. The first is to directly modify the
actual source code; the second is to generate the corresponding bytecode
into the class file; and the third is to create an intermediate, modified,
version of the source code and then compile that.
The first approach is a problem in an IDE, because it means that as you're
editing one part of the file you're causing another part of the file to
change. Supporting that requires architectural changes throughout the IDE;
it's not something that can be tacked on afterwards. It's also a problem
for many version control systems, because it means that a source file may be
changed as a result of being built. This same violation of the conceptual
boundary between source and output manifests in other ways: for instance,
what should happen if the generated part of the file is manually changed?
Basically, a lot of the toolchain relies on the assumption that source code
changes only as a result of a user acting upon it, and when that assumption
is violated, things break.
The second approach does not violate the separation between source and
output. But it does mean that the output is no longer easily traceable to
the source. For instance, what should happen when you debug through the
generated code? The generated code is not actually in source, so in order
for it to be seen it would need to be re-generated on the fly by the
debugger. But what if the debugger does not have access to the same version
of the annotation processor that was originally invoked to compile the code?
On the other hand, if the generated code is not going to be visualized, how
to support debugging - in particular, debugging of the annotation processor?
As a sidebar, historically Sun has threatened to sue manufacturers of
compilers that generate byte code that is not the direct result of the Java
input, on the grounds that this is changing the definition of the Java (TM)
language, which they license. Finally, it makes the compiler's task
considerably more complex, because it means that all source file access must
be virtualized, since any type being referred to (including types that
haven't yet been compiled) might ultimately have additional fields and
methods that don't correspond to what's on disk.
The third approach might in principle be made to work. Essentially, the
compiler would have to put the generated source folder on the classpath
ahead of the "original" source folder. However, if you think about the
compilation process, it gets pretty tricky: for instance, what if the
annotation processor generates annotated code, calling for another round of
processing? Do you end up with an unbounded series of generated source
folders, to be created (and named) on the fly? Which one should get
included into the source code archive, and how does the debugger know where
to look? What should happen if an intermediate file is manually edited?
You are right that this limitation puts some real restrictions on what
annotation processors can be used to do. Depending on the particulars of
your use case, it may be better to simply use a wizard, refactoring
operation, etc. to generate the source code in response to a user action,
like how the "generate getters and setters" action in Eclipse works. These
actions can be very sophisticated and have full access to the AST of the
source code. Another possibility is to use the annotation processor to
generate an implementation class, using a factory or facade pattern. In
certain cases, another possibility is to perform the desired actions at
runtime in the application container rather than at compile time, using
annotations with runtime retention.
Hope that helps,
-Walter Harley
JDT APT team
|
|
|
| Re: code generation using annotation processor framework [message #250985 is a reply to message #250278] |
Sun, 27 January 2008 19:00 |
| Eclipse User |
|
|
|
Hi Happy New Year! As far as the APT processor is concerned, do you think
there is anything that is worth providing as common utilites for different
users who use the APT proceesor? From the look of it, the APT framework
itself
is designed in such a way that it is very easy and simple to use. So there
will not be any common framework that we should be able to provide on top
of it.
Just want to hear the expert's opinion. What about validation/performance
related stuff?
|
|
|
Powered by
FUDForum. Page generated in 0.04693 seconds
Home