Hello Mickael, This is a very lucid articulation of why whatever is being attempted is being attempted. This should serve to dispel confusion/anxiety about future
that may have otherwise taken root. Thanks! Your rationales are valid and sound.
Hello Mickael,
This is a very lucid articulation of why whatever is being attempted is being attempted. This should serve to dispel confusion/anxiety about future that may have
otherwise taken root. Thanks!
Your rationales are valid and sound. I must say, I am mildly disappointed to read you are “betting on javac long term” – with the implied exclusion of any bets
on ECJ by my reading - but that is your prerogative 😊
Funding/resource situation being what it is I can’t find fault. I was working for Oracle on javac for 8 years before my return to JDT and believe me, we can’t
compete on resources – not even remotely!
I am inclined to take your assertion at face value and can believe that this initiative “serves JDT in general, without harming ECJ. At the moment, that's a win-win
and safe situation.”
Overall, the only thing that alarms me about this is the talk of merge back to upstream – my preference is that the product should be completed, enjoy adoption and should be seen to be thriving and seen to be maintained well before merge
back. Until then, I prefer that it should stay as a separate plugin, in a separate repository whatever. Enabling APIs may certainly be added as needed to JDT/Core.
If this is stipulated, personally I will be relieved. Otherwise, both from a source code pov and a product pov this double headed beast nature makes me uncomfortable.
Surely such a plugin level isolation is possible I would imagine and is being actively considered.
I work part time and am already drowned in compiler work as I am, so I am personally unable to contribute, but I am happy to cheer for this.
Speaking for myself.
Thanks
Srikanth
CAUTION: This email was sent
from outside of Advantest.
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.
