Community
Participate
Working Groups
Xtend (http://www.xtend-lang.org) integrates tightly with the JDT, using all kinds of available extension hooks. This allows to navigate to java files from Xtend, have content assist including all the JDT elements and so on. Also we are working on support for JSR45 which will allow to debug through Xtend code using JDT debugger. As you know, this even allows to navigate to the Xtend source by clicking on stack traces. So far all this could be accomplished without using any AOP technique. Unfortunately there is no hook to tell JDT how to select and reveal a Java element derived from some other source in an editor. That's why you always end up in the generated Java source if you click on such Java elements in call hierarchy, type hierarchy, navigation, etc. As we would like to stick to the no-AOP solution, I'd propose to introduce an extension point where languages like Xtend can hook in to decide what editor and what selection to open for a certain Java element. We are going to work on this and provide a patch very soon. So it would be good to hear about your opinions on this.
Wouldn't you primarily want feedback from JDT/UI so as to hook into s.t. like org.eclipse.jdt.ui.JavaUI.openInEditor(IJavaElement, boolean, boolean) ? I wouldn't know how JDT/Core can help here. If s.o. is already working on a patch, which classes would you like to see modified? (If you don't like AOP, use OT/J, it achieves the same but a lot cleaner :) )
> I wouldn't know how JDT/Core can help here. If s.o. is already working on > a patch, which classes would you like to see modified? We have a preliminary version working and are already using it internally for testing purpose. Modifications were necessary in the EditorUtility to some extend in clients of JavaUI / EditorUtility that did use ITextViewer#reveal directly instead of JavaUI#reveal / EditorUtiltity#reveal. For now we did not face any issues with the patched JDT version so I expect a first version of the patch to be attached in the next week. For the curious: the code can be found here: https://github.com/szarnekow/eclipse.jdt.ui/commits/javaElementOpeners Moving to JDT/UI since no classes from JDT/core are affected in the patch.
We will most likely not provide this hook. JDT is (currently) not meant to be a framework to build Java-like languages but to provide pure support for Java as defined by the specs (JSRs). There was some movement to work on such support in an e4 incubator but AFAIK not much has happened there (see bug 36939). I think you can achieve most of what you want already now: 1. register an editor launcher that implements the delegation 2. register that editor to the Java content type 3. set your editor as default.
(In reply to comment #3) > We will most likely not provide this hook. JDT is (currently) not meant to be > a framework to build Java-like languages but to provide pure support for Java > as defined by the specs (JSRs). It's not about opening up JDT to build new languages with it. It's just about allowing tighter integration with other JVM-languages and a more seamless experience for the user. This hook would for instance also be very interesting for JSPs (e.g. call hierarchies and find references) and might complete the already existing support (JSR-45 i.e. debugging for JSP and the like). The changes are not very big and also not too invasive. We tried to be very defensive and apply the JDT coding styles are willing to do as many review cycles as needed. Of course this must not affect any of the existing JDT experience. Going the AOP-way hurts JDT, since plug-ins hook in in incompatible and invasive ways. For instance if you have the latest Scala IDE (2.0) installed you will have all kids of Scala-specific template proposals in the Java-Editor. Also having multiple plugins modifying JDT is very problematic and will unfortunately give JDT a bad name, since user's perceptions are often not so nuanced. Providing the extension point in question will allow plugins not to go this way but play nicely with JDT.
(In reply to comment #4) Did you try the launcher approach?
(In reply to comment #5) > (In reply to comment #4) > Did you try the launcher approach? Not yet but we will. I can imagine it might work to open up the right editor, but I'm wondering how we can translate the reveal call (the ranges are different). Anyway we'll try and report.
(In reply to comment #4) > Going the AOP-way hurts JDT, since plug-ins hook in in incompatible and > invasive ways. For instance if you have the latest Scala IDE (2.0) installed > you will have all kids of Scala-specific template proposals in the Java-Editor. This mainly shows that the Scala IDE is missing some checks to avoid their adaptations to leak into wrongs contexts. This could (and should!) be done better.
(In reply to comment #7) > (In reply to comment #4) > > Going the AOP-way hurts JDT, since plug-ins hook in in incompatible and > > invasive ways. For instance if you have the latest Scala IDE (2.0) installed > > you will have all kids of Scala-specific template proposals in the Java-Editor. > > This mainly shows that the Scala IDE is missing some checks to avoid their > adaptations to leak into wrongs contexts. This could (and should!) be > done better. Sure, I wanted to point out that it's not in your but in their hands now, which would be different with explicit extension points and public API.
> I can imagine it might work to open up the right editor, but I'm wondering how > we can translate the reveal call (the ranges are different). The revealing wouldn't work. For that you'd have to register an editor part which would delegate all calls. The new 'org.eclipse.ui.ide.editorAssociationOverride' extension point (coming with 3.8 M5 next week) offers another possible way to solve your problem.
