Community
Participate
Working Groups
This is not a feature request per se, but just an idea that deserves to be tracked (and maybe honoured later). As per blogs and comments on http://cdtdoug.blogspot.fr/2013/08/my-favorite-thing-about-blogging-is.html , it appears that DLTK has copied a lot of behaviour of JDT and that most of other languages plugins rely on DLTK. DLTK seems to provide the right level of abstraction for any language, including Java. So it would make sense to re-write JDT on top of DLTK so there would be a better factorization of everything related to programming language tools. With that, we can expect a high quality on DLTK (which would benefit from feedback from its various usage) which would lead to high quality for all programming language tools.
Sounds great, but who would be the (large) team of developers pushing this rewrite? It seems like the main benefit would not be for JDT but for other *DT projects. Which ones of those are willing to assign how many full-time developers to this effort? To me this sounds more like a project proposal than a request against an existing project. In a project proposal you would list the initial committers, interested parties etc. so we can estimate whether the initiative is viable or not.
(In reply to comment #1) > It seems like the main benefit would not be for JDT but for other *DT > projects. The benefit is for both: sharing the common part instead of duplicating them makes that with the same amount of effort, you produce more value (eg a fix coming from JSDT would benefit to JDT as well, and vice-versa). > Sounds great, but who would be the (large) team of developers pushing this > rewrite? > Which ones of those are willing to assign how many full-time > developers to this effort? As usual: anyone who want to do it can do it... It is actually an optional change (not a major bug). So let's just leave this idea somewhere and wait for the time when someone will find it interesting enough to work on it. If you (and other) think it's a good idea, it could be interesting to start a wiki page where JDT/DLTK expert could list the potential issues and increments to carry on this effort. So one could more easily evaluate the effort it represents and maybe plan some contributions.
We've brought up common language infrastructure before. I'm not totally sold that simply copying the JDT was the right thing for DLTK. And JSDT for that matter which also copied JDT and even left most of the classnames the same. I think we need a deeper introspection on what a common language infrastructure should include then grab pieces from the various projects to start it. Maybe it would be better to start with a new language we think needs being added (like C# or Objective-C) or one that needs a redo (JSDT?) than JDT itself. I'll bring this up on ide-dev to see if there's any other ideas out there.
See http://www.eclipse.org/org/langsymp/ - long time ago in 2005 we tried to find/build a common ground. That effort died for several reasons: complexity, existing code worked, focus on new features more important for projects (e.g. adopt new Java versions), lack of resources, .... I agree with Stephan that this is a separate/new project where interested parties would commit to build a common language layer/toolkit and not something that JDT will have to own.
(In reply to comment #4) > See http://www.eclipse.org/org/langsymp/ - long time ago in 2005 we tried to > find/build a common ground. That effort died for several reasons: > complexity, existing code worked, focus on new features more important for > projects (e.g. adopt new Java versions), lack of resources, .... > > I agree with Stephan that this is a separate/new project where interested > parties would commit to build a common language layer/toolkit and not > something that JDT will have to own. Thanks, Dani! OMG, I forgot about that. 8 years ago. But all the points are still valid. I'll forward this to the ide-dev list. And you are right, this is starting to lean towards a common language project where we can start working on this layer.
The issue I see with having such a common language framework developed independently and externally of existing *DTs is that if it is not adopted by the various *DT while it is still being developed, it will have a poor quality, won't match the requirements of the various projects, so in the end, it won't be used. Such a project would only succeed if most *DT projects would be ready to migrate progressively to the comment LTK stuff as it is being developed. This langsymp is a great resources if we go for developing a common LTK. It should be reviewed by most *DT project representatives so they'll identify if it would be do-able or not to migrate pieces of their *DT project to LTK.
I'm of two minds of this idea. I think it is obvious that having a common language infrastructure is a great idea, but is it worth it for existing *DTs to move to it if existing code works? Things are too far along to go for a rewrite. A perhaps less ideal, but more realistic approach is to think of the features that should be cross-language, but currently are not, and then provide a set of extension points and common infrastructure to integrate them. I'm thinking of features like cross-language search, navigation, content assist, refactoring, etc. This is kind of idea already exists in the Common Navigator, which is fairly successful (even though it does have some roughness around the edges). A common language infrastructure would be possible to build incrementally and existing *DTs could take advantage of it piecemeal. So, something like this seems more realistic to me.
(In reply to comment #7) > A perhaps less ideal, but more realistic approach is to think of the > features that should be cross-language, but currently are not, and then > provide a set of extension points and common infrastructure to integrate > them. > I'm thinking of features like cross-language search, navigation, content > assist, refactoring, etc. > > This is kind of idea already exists in the Common Navigator, which is fairly > successful (even though it does have some roughness around the edges). > > A common language infrastructure would be possible to build incrementally > and existing *DTs could take advantage of it piecemeal. So, something like > this seems more realistic to me. I fully agree with this approach. The same way as LTK already provide API for refactoring, we could think about copying some some generic stuff of JDT into the LTK project (for example org.eclipse.ltk.indexing, org.eclipse.ltk.contentassist...) in a generic way and abstracting the Java specific part so it could be used by all *DT if they want (directly as an API, or by specializing the API via extensions). The goal is not to rewrite stuff without providing additional value, but factorize code and effort by moving it to a shared place where we can hope to get more feedback from more use-cases and more contributions.
Piecemeal sounds reasonable. To get this road unblocked maybe we should first understand why the prominent bug 36939 failed to deliver, as an example. I think we all agree that the world would be better with less duplication and a richer platform to be shared by many. I have two severe concerns, however: 1) Who are the actors in this theatre: who is willing to invest his/her own time? How much? I'm afraid JDT has more than enough on our plates (remember Java 8) so we can't even promise a single person month for this effort (and it seems we are talking more like several person years, right?) 2) It might turn out that any change we make in JDT would break hundreds of plug-ins out there, which are developed against the existing API. Do we actually have the freedom to build a JDT-on-top-of-LTK? This question may lead us back to bug 36939. So here's my 2c on bug 36939: evolving the API in a compatible way is quite painful even for small changes. In the end, the few providers of IDEs for Java-like languages found the following approaches to be less painful: a) deploy a patched JDT/Core b) weave into JDT (using AspectJ or Object Teams) Approach a) means, you can only have one plug-in of this kind installed at a time. Approach b) is - in theory - composable, details will always need to be worked out. That story was about Java-like languages that need only "minor" adaptations of JDT. For entirely different languages a) and b) are probably not applicable, that's why we see full source copies, right? Now, *how severe* is the pain caused by these copies? *How much* momentum can we gain from the vision of a better approach? ATM this request sounds a bit like wishful thinking. If people/projects really pledge a budget in terms of person months, maybe this gives more solid grounds for planning. The word "committer" is derived from "committment", isn't it? :) Who?
I also think we need to make sure we're thinking of all the cases, not just the Java-centric ones :). A common scenario we're seeing is bridging between JavaScript and C++. That's been around forever with browser plug-ins, but now also Qt has similar concepts. Navigating cross-language is an uber feature that not many other IDEs do well (if at all) which we could address here.
Let's worry first about what we want. If we focus on who, nothing will ever get done. If we document what we may be able to attract new blood.
My experience with Bug 36939 was that there is no way to implement without breaking API and keeping the patch small. We discussed two possible solutions (one was on the bug report itself, and the other only offline): 1. Create a concept of 'internal API' that is not stable like regular API, but is something that third party tools are expected to extend. Perhaps a more formal definition of internal API is that it can change between minor releases (eg- 4.3 to 4.4). This means that third party tools would need a new release every year that would not be backwards compatible. This is a sacrifice that I think most DTs would be willing to make. 2. Create a wrapper API (perhaps living in LTK) that JDT already implements and expose this API to other DTs. I personally like #1 better since it would require less mew code. It would mostly consist of elevating existing non-api code to internal API. However, this approach is much more Java/JVM centric and so may not be scalable.
(In reply to comment #6) > The issue I see with having such a common language framework developed > independently and externally of existing *DTs is that if it is not adopted > by the various *DT while it is still being developed, it will have a poor > quality, won't match the requirements of the various projects, so in the > end, it won't be used. > Such a project would only succeed if most *DT projects would be ready to > migrate progressively to the comment LTK stuff as it is being developed. > I agree. Such a project needs to be backed by existing *DTs IDEs to validate its usefulness and adequacy. Absolutely essential. And with that in mind, I think the best approach is to work with the DLTK project. There is not enough manpower to start a whole new project, and of all those well-meaning ideas and hopes from 2005, it's the only project that has come out so far with this goal of extending Eclipse's *DTs IDE support, and succeed at that. By "success" I mean it is actively maintained, and actually got significant adoption, see: http://wiki.eclipse.org/DLTK_Based_Projects Quite a few projects there, and at least 1 or 2 (PHP and LDT) are significant players in the *DT sphere. There are still a lot of rough edges in DLTK (as an example, DDT, the IDE I work on is for a native, compiled language, so there are these quirks in the UI where things are called "interpreter" instead of compiler, and the project view is the "Script Explorer", etc.). But using DLTK was still by far the best alternative.
(In reply to comment #10) > I also think we need to make sure we're thinking of all the cases, not just > the Java-centric ones :). > > A common scenario we're seeing is bridging between JavaScript and C++. > That's been around forever with browser plug-ins, but now also Qt has > similar concepts. > > Navigating cross-language is an uber feature that not many other IDEs do > well (if at all) which we could address here. Whoa there. Yes, cross-language IDE support would be cool in several contexts, but isn't it asking for too much at this point? I would say it's better to get a good level of framework support for the development of new (single-language) IDEs before moving on to even loftier goals.
(In reply to comment #10) > Navigating cross-language is an uber feature that not many other IDEs do > well (if at all) which we could address here. afaics both intellij and netbeans has this - so I would say Eclipse is the IDE that doesn't do it yet. Just my 2 cents.
> > Navigating cross-language is an uber feature that not many other IDEs do > > well (if at all) which we could address here. > > afaics both intellij and netbeans has this - so I would say Eclipse is the > IDE that doesn't do it yet. > > Just my 2 cents. Actually, if we are being JVM-centric, Java<->Scala, Java<->AspectJ, Java<->Groovy navigation all work quite nicely. But, this all happens through some trickery that is not proper to talk about in polite company (i.e., weaving and patching).
Yes, but even those weaved and patched tools all reimplement alot of things other IDE's has as shared code/behaviors.
(In reply to Max Rydahl Andersen from comment #17) > Yes, but even those weaved and patched tools all reimplement alot of things > other IDE's has as shared code/behaviors. I don't know which other IDEs you're referring to. All I know is that using Object Teams I'm practising re-use at a level that will never be achieved using mechanisms of Java and OSGi alone :)
> I don't know which other IDEs you're referring to. I guess NetBeans and IntelliJ... > All I know is that using Object Teams I'm practising re-use at a level that > will never be achieved using mechanisms of Java and OSGi alone :) What I understand from Max comment is that other IDEs have prefered a better factorization of the Development Tools for the various languages over the patch/aspects/forks most Eclipse Development tools have chosen. That's the whole purpose of this discussion: better factorization of Development Tools, starting by JDT which probably contains the most powerful API that could be generalized for other languages. This page helps to list the various approach used http://wiki.eclipse.org/Languages_Tools_Factorization . You could add your insights about OTDT. Hopefully, this page will lead to extraction of generic features that could be better re-used by *DT.
Changing title to something that better reflects the discussion.
(In reply to Mickael Istria from comment #20) > Changing title to something that better reflects the discussion. Mickael, can you point to something that can be decoupled from jdt without major disruption and moved to ltk ?
At this point, it would be good to start seeing code examples of what we want to see.
(In reply to Stephan Herrmann from comment #18) > (In reply to Max Rydahl Andersen from comment #17) > > Yes, but even those weaved and patched tools all reimplement alot of things > > other IDE's has as shared code/behaviors. > > I don't know which other IDEs you're referring to. > All I know is that using Object Teams I'm practising re-use at a level that > will never be achieved using mechanisms of Java and OSGi alone :) Object Team's JDT patch is example of how bad the current situation is. Its all good object team want to extend it but the amount of time everyone else have to spend on disabling/filtering out Object Team JDT patched bundle so JDT will actually build/work as expected is problematic. Afaics your features cannot coexist with what scala/groovy projects do either - that is part of the problem here.
(In reply to Max Rydahl Andersen from comment #23) > (In reply to Stephan Herrmann from comment #18) > > (In reply to Max Rydahl Andersen from comment #17) > > > Yes, but even those weaved and patched tools all reimplement alot of things > > > other IDE's has as shared code/behaviors. > > > > I don't know which other IDEs you're referring to. > > All I know is that using Object Teams I'm practising re-use at a level that > > will never be achieved using mechanisms of Java and OSGi alone :) > > Object Team's JDT patch is example of how bad the current situation is. > > Its all good object team want to extend it but the amount of time everyone > else have to spend on disabling/filtering out Object Team JDT patched bundle > so JDT will actually build/work as expected is problematic. > > Afaics your features cannot coexist with what scala/groovy projects do > either - that is part of the problem here. Is there a bug open on that? Nothing Object Team does should affect other extensions to the JDT.
(In reply to Doug Schaefer from comment #24) > Is there a bug open on that? Nothing Object Team does should affect other > extensions to the JDT. This has been discussed many times in various bugs. Let me try to identify the different issues involved: Object Teams uses two different techniques for different parts of the IDE: - jdt.core is patched using a patch feature - everything else is adapted using weaving. It's the latter that I was referring to in comment 18 and this can in principle coexist with other extensions (details to be discussed elsewhere). The jdt.core patch is a special case, because we don't deliver an IDE for a completely separate language but for a language that is a superset of Java. Let's simplify the discussion by saying: the patch is the only technical possibility for implementing the OTDT. The inevitable downside of this is that OTDT and Groovy IDE cannot coexist in one installation (both patch the same core - no other extensions that I know of are affected). The problem that Max is referring to ("disabling/filtering out Object Team JDT patched bundle") is a simple disagreement how p2 should handle patch features during update. Object Teams did all that is in our powers to prevent the patch feature from being proposed for *update*. Help from p2 has been "sporadic" - it's an open bug against p2 for some months / years.
(In reply to Stephan Herrmann from comment #25) > The problem that Max is referring to ("disabling/filtering out Object Team > JDT patched bundle") is a simple disagreement how p2 should handle patch > features during update. Object Teams did all that is in our powers to prevent > the patch feature from being proposed for *update*. Help from p2 has been > "sporadic" - it's an open bug against p2 for some months / years. OK, but then are we intentionally causing problems for IDEs like the Groovy IDE by putting ObjecTeams into the same repo as JDT knowing this bug hasn't been fixed yet?
Guys, just to be clear - I don't think this bugzilla is the place to discuss a resolution to the specific object team issue. Just pointing out that the approach Object Team have felt forced to do is a symptom of what is wrong/missing/lacking in eclipse as IDE.
(In reply to Max Rydahl Andersen from comment #27) > Guys, just to be clear - I don't think this bugzilla is the place to discuss > a resolution to the specific object team issue. > > Just pointing out that the approach Object Team have felt forced to do is a > symptom of what is wrong/missing/lacking in eclipse as IDE. Agreed, I'm just trying to understand that comment. What do you think we're missing then that would fix this symptom?
(In reply to Max Rydahl Andersen from comment #27) > Guys, just to be clear - I don't think this bugzilla is the place to discuss > a resolution to the specific object team issue. I tend to agree, except: it was you who said that Object Teams has an issue, we are basically (except for that p2 bug) fine with the current solution :). BTW, anybody wanting to understand the complexities of building an IDE for a Java extension is invited to first read http://wiki.eclipse.org/OTDT/JDTCore
Alot of the issues could be fixed or at least reduced if JDT would have hooks for reusing their infrastructure to provide support for at least JVM based languages. http://wiki.eclipse.org/OTDT/JDTCore seem to highlight many of these issues and i'm sure authors behind scala and groovy support can chime in too - just like they did at EclipseCon 2010(?) where there was a meetup to try avoid some of these things. Next step would be more core support in eclipse for languages in general - looking at how intellij and netbeans handles that would be interesting.
(In reply to Max Rydahl Andersen from comment #30) > Next step would be more core support in eclipse for languages in general - > looking at how intellij and netbeans handles that would be interesting. Yes, I've heard good things about intellij's multi-language support.
*** Bug 533971 has been marked as a duplicate of this bug. ***
As mentioned by Dani in duplicate bug, part of this effort would also to move/duplicate generic parts/extension points of JDT to a layer that do not require UI and does not assume we're running a workbench. Having that would be highly profitable for JDT.LS which could use the factorized parts. The extensions that are cuurently missing for a better extensibility in JDT.LS and that would make sense in a LTK Core are * completion proposal * hover Validation/Diagnostics/Markers/Builders are already on the resource layer, so that's good. But * Quickfix/MarkerResolution : while this is not so dependent on UI, the IMarkerResolution class is part of a UI bundle (org.eclipse.ui.ide) and should be moved to a core part.
(In reply to Mickael Istria from comment #33) > As mentioned by Dani in duplicate bug, part of this effort would also to > move/duplicate generic parts/extension points of JDT to a layer that do not > require UI and does not assume we're running a workbench. I believe we may be able to simply copy the existing interfaces from JFace and extension points from the generic editor (for content-assist, hover and so on) and to replace methods requiring the ITextViewer by method requiring a org.eclipse.jface.text.IDocument. Then, we could have the main editor (AbstractTextEditor, ExtensibleEditor, JavaEditor...) classes able to consume those new classes as well as the JFace based ones by adapting those document-based classes into JFace-based classes.
