| Re: [jdt-dev] Proposal for improving JDT Core and JDT LS |
Hi Gayan,
I hoped to meet you at EclipseCon :), but it seems you're not
here?
A quick question to get the discussion going: are you aware of the plugin org.eclipse.jdt.core.manipulation? If so how would your proposal relate to it?
In my understanding an incremental process of moving things from
JDT/UI to jdt.core.manipulation is under way already (slowly
perhaps, I don't know), for exactly the reasons you are giving. I
may be missing something.
best,
Stephan
Hi All,
I have been fixing bugs in JDT Core and JDT LS for some time now and I have seen the following improvements that we can make.
Today JDT Core provides the parser and compiler language engine for JDT LS. But when it comes to things like refactoring and completions most of the logic is UI centric.
One way forward is to move them into JDT Core by making those logics headless and then apply the UI parts on top of that. This requires log of work on both JDT Core and JDT UI. I guess none of the team, JDT or JDT.LS has that amount of resources.
So here is my proposal.- We move all the current JDT.LS logics that are not part of LSP into JDT core, so that it can be reused anywhere, either by JDT UI or any other layer that will be built on top of JDT.Core in future. This will introduce some new extension points into JDT.Core for things like completion computers, sorters etc. To keep things backward compatible we could only process this extra extension only when called from this new proposed APIs/Facades. We need to have a good design here which aligns with JDT design.
- Implement refactorings and quick fixes in JDT Core and use them in JDT.LS. Again these components can be reused by JDT.UI or any other future layer built on top of JDT.Core
This will result in some duplicate logic in JDT.Core and JDT.UI. But over time we can refactor JDT.UI to use more and more headless components in JDT.Core. For example when fixing a bug in JDT.UI that particular area can be refactored to use the headless component.
The reason I suggest this is, JDT.Core team is super busy with adapting to Java Language changes. So we could use JDT.LS team and contributors to work on these things with some JDT committers which will make JDT.LS catch up with JDT features. For example Apache Netbeans LS supports more refactorings and features than JDT.LS the last time I checked.This will make the move and adaptation of feature faster than the trying to refactor the JDT.UI and move logic into JDT.Core and use them in JDT.LS route as I feel.
What do you all think ? Open for feedback and different approaches.
Best regards,Gayan.
_______________________________________________ jdt-dev mailing list jdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev