|
|
|
| Re: code generation using annotation processor framework [message #250263 is a reply to message #250260] |
Tue, 18 December 2007 21:17   |
Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Ivy" <ivyho@ca.ibm.com> wrote in message
news:1a43cc34128b6660a186aadae88e77de$1@www.eclipse.org...
> Thanks for your reply.
>
> Regarding renaming the folder into another folder name other than
> "apt.generated". Is there any API that we can do it programtaically
> instead of during it manually in the UI?
Sure. The APT config options are available through
org.eclipse.jdt.apt.core.AptConfig and ...AptPreferenceConstants.
Generally the way those config APIs are used is from within a project
creation wizard, rather than from within a processor.
|
|
|
|
| Re: code generation using annotation processor framework [message #250278 is a reply to message #250274] |
Wed, 19 December 2007 00: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
|
|
|
|
Powered by
FUDForum. Page generated in 0.05797 seconds
] 
Search
Help
Register
Login
Home
