Hi Alexander,
Note that the ongoing development to use Javac instead of ECJ in JDT is not excluding ECJ at all. ECJ is and will remain default backend, and Javac is and will remain an opt-in (until there is enough maturity and consensus to change that, but it's not something to happen soon enough to worry IMO). What we do want is to provide integrators a choice of which strategy to use to build DOM & Model, either ECJ or Javac (because our team bets on Javac on longer-term). Both ECJ and Javac-based code can (and do and will) easily live together in the same codebase, there is no benefit and thus no plan to remove ECJ classes nor to break them in anyway. So as long as integrators don't explicitly require to use Javac backend, then they stick on ECJ, and it doesn't change anything to them and things would still work. AspectJ and others will still work as long as ECJ is maintained, even if we are introducing an alternative Javac backend.
The concerns you express are more about future ECJ maintenance, but the work we're doing doesn't really change much to the statuquo. It's actually not removing any active contributor to ECJ development, but it's currently adding contributors to higher-level (DOM, bindings, model...), as they are heavily considered and slightly consolidated thanks to this JDT-over-Javac development. So overall, the work we're doing here serves JDT in general, without harming ECJ.
At the moment, that's a win-win and safe situation.
Cheers,.
