| Re: [aspectj-dev] Dynamically defining fields |
Gregor Kiczales wrote:
You're absolutely right - this would work, assuming that the second stage worked off of _source code_ and not compiled class files, since user code may utilize the variables which are to be weaved, and thus the code will not compile until *after* the weaving has taken place.As you've noticed, AspectJ won't do this for you automatically. In general, ApectJ's code generation facilities are limited. That was done intentionally. The AspectJ focus is on AOP. But there is a way that AspectJ may be useful to you as part of your solution. Several people have done this before, so its not novel, but I don't know if its written down. A common problem with the kind of code generation you are talking about is that the generated code is scattered (and tangled) across a number of files. That can get you into complex compile structures, because you want to avoid having the generator output to the original sources etc. So the trick is to have the generator output a modular aspect, and then let the AspectJ compiler weave the definitions into a number of output class files. One way to think about this is as a two stage compiler. The first stage goes from a high-level statement that the existence of certain methods implies the existence of certain fields, and generates a declaration for each such field, in a single aspect. The second stage then weaves those fields throughout the code.
Given this. there are two choices (maybe more?). One is that each stage is a separate process, the first parsing the source code and creating an aj file, the other process would then parse the source code+aj, and weaving a .class file. The other choice merges the two stages into a single process, in effect, creating a 2 pass compiler. I assume (please correct me if I'm wrong - my compiler theory is a little rusty!) that ajc (and javac for that matter) is a two-pass (or at least a 1.5 pass) compiler. That is, because there is no requirement in java to forward delcare variables, a compiler must resolve references after the parsing has completed. Given that references are resolved after-the-fact, I could imagine that a reference be artificially created during the first pass, and successfully resolved in the second pass.
The question becomes (to which I don't know the answer, perhaps someone else does?), does AJC only work on code that successfully compiled *prior* to weaving, or is it possible to write a method that won't compile, and an aspect that completely overrides that method, run ajc on the source+aj, and produce a valid .class file?
I recognize that this is not the "usual" use case for aspects, because it isn't really cross-cutting. I know that there were tools designed specifically for pre-processor type of behavior. Usually, these tools require modifications to the language (eg, added keywords). AspectJ is at least a post-processor (possibly a pre-processor (in effect, at least), depending on the answer above), but defines it's own language, keeping the java language pristine. Having a tool which acts as a pre-processor (in effect, at least) without having a pre-processor, and modifying the language accordingly. Given that we already utilize AspectJ for other cross-cutting concerns, we were hoping to utilize (or expand) on some of the other use-cases for which a pre-processor may be used.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature