Re: [jdt-core-dev] Understanding and optimizing levels of compilation

[Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>]

On Tuesday 11 October 2005 09:04, Philippe P Mulet wrote:
> Re: 1.
> Aside from produce a resolved DOM AST, this API is also meant to detect
> problems. Unless you run all the stages of compilation, then you may miss
> some of them. I agree that producing in memory classfile is a waste of
> time, but our performance measurements show that this is not that
> expensive. Now, if you have some particular offending scenarii, please
> speak up.
I have no scenarii that could prove a performance problem. It's just my
intuition while trying to understand the code and its dependencies
that suggests that the compiler is doing more than needed.

When checking your statement against some samples of the code
I see only one kind of problem being detected as late as code generation:
issues with unavailable/unneeded enclosing instances (which I guess could 
already be detected during analyzeCode).
On the other hand clients of the ASTParser (at least _within_ the JDT) 
are typically interested in _parsing_ errors.

Was the intention to keep the API simple, and thus not expose any flags
by which different levels of investigation can be requested?

---

Here is an example of a conceptual problem which follows from the given
design in the context of our extension:
1. In our language we support to store so-called roles (for this issue think
  of them simply as inner classes) in separate files/compilation units.
  By this we support separate/incremental compilation of inner classes ;-)
2. Each "new" statement for a role must internally be transformed into a
  method call to the enclosing instance (due to the semantics of the language)
3. Thus a role that contains a "new" statement referring to a sibling role 
  depends on the full transformation of that sibling role.
4. Further dependencies arise during byte code generation because we need
  to copy some byte-codes between classes.
Without going more into detail: these kinds of additional dependencies make
it quite difficult to create a fully compiled AST of, e.g., just one inner 
class. The real problem is transitiveness of such dependencies. 
OK, these are my problems, not yours ;-)

---

However, I thought it might help both you and me, if at least the last phase,
byte code generation, were (in general) excluded from createAST(), don't you 
think? Have I overlooked any relevant problems that _can_ only be reasonably 
detected during generateCode() (except from constant pool size exceeded ;-)?


Thanks for looking at this
Stephan