Community
Participate
Working Groups
The features listed at https://www.eclipse.org/recommenders/manual/#intelligent-code-completion seem pretty nice. Given that Recommenders isn't part of the Java/JEE EPP, Or Oomph, many users probably don't know about this if they don't do a bit of research. Is there any reason some of these features were not proposed for inclusion ? As an example, I've taken https://github.com/eclipse/recommenders/blob/master/plugins/org.eclipse.recommenders.chain.rcp/ , and stripped it down to about 8 classes, removed 3rd party deps, and have something that could be contributed to JDT UI. All that remains is to use JDT public API (for the AST, and Bindings) as opposed to some JDT internal compiler APIs (to not have to rely on x-friends of jdt.core). Would such a change be wanted in JDT ?
(In reply to Roland Grunberg from comment #0) > The features listed at > https://www.eclipse.org/recommenders/manual/#intelligent-code-completion > seem pretty nice. > > Given that Recommenders isn't part of the Java/JEE EPP, Or Oomph, many users > probably don't know about this if they don't do a bit of research. Is there > any reason some of these features were not proposed for inclusion ? > > As an example, I've taken > https://github.com/eclipse/recommenders/blob/master/plugins/org.eclipse.recommenders.chain.rcp/ > , and stripped it down to about 8 classes, removed 3rd party deps, and have > something that could be contributed to JDT UI. All that remains is to use > JDT public API (for the AST, and Bindings) as opposed to some JDT internal > compiler APIs (to not have to rely on x-friends of jdt.core). > > Would such a change be wanted in JDT ? I'm fine with this and AFAIK it's OK to use that code but to be sure, please send a note to license@eclipse.org asking whether this is OK and whether we need to file a CQ, and please cc me on that e-mail.
Just to follow up, legal has confirmed that there's no need to file a CQ. Where modifications are required we can update the copyright headers as needed (eg. And Others) The feature can be accessed on the chain-completion branch at https://github.com/rgrunber/eclipse.jdt.ui/tree/chain-completion . I'm just in the process of polishing the contribution and porting over the testcases for chain completion.
Awesome news Roland, AFAIK this is the best offline code recommenders feature.
Hi @Roland, Do you have any plans to port other completion computers as well from code completion into this ? like the SubType, Call and Constructure. Basically they bring up the proposals from JDT to top according to the receiving type. Once i tried to implement the SubType based on the JDT Index and the subtype search was pretty slow.
(In reply to Gayan Perera from comment #4) > Hi @Roland, Do you have any plans to port other completion computers as well > from code completion into this ? like the SubType, Call and Constructure. > Basically they bring up the proposals from JDT to top according to the > receiving type. Once i tried to implement the SubType based on the JDT Index > and the subtype search was pretty slow. I actually started a patch for this as it seemed quite beneficial. For now it just increases relevance for method completions that match the type exactly, https://rgrunber.fedorapeople.org/method-proposal-context.webm . However, I plan to adapt it to match if the proposal is a subtype as well. I'll look at the performance, but given that chain completion has to do the same thing and evaluate chains of size > 1, it should be fairly quick. I can make a separate bug for this work.
Another code completion, which is very popular in IntelliJ is postfix completion. See Bug 458804, would be great if you good have a lock at it Roland.
@Lars you had a fork of the tryLimits postfix implementation right ? Can't we polish it and bring that to JDT. i wonder how the licensing will effect on the original work of the author.
(In reply to Gayan Perera from comment #7) > @Lars you had a fork of the tryLimits postfix implementation right ? Can't > we polish it and bring that to JDT. i wonder how the licensing will effect > on the original work of the author. Let's discuss in Bug 458804
@Roland any update on this work ?
New Gerrit change created: https://git.eclipse.org/r/141902
@Roland does this patch handles the scenario described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=543101 as well ?
(In reply to Gayan Perera from comment #11) > @Roland does this patch handles the scenario described in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=543101 as well ? No, but for a separate reason. I was using getExpectedType(), which is wrong because it ultimately calls 'stripSignatureToFQN(..)' which strips away type parameters and arrays. Once this is fixed, I can see if it handles this case or if more work is needed.
Gerrit change https://git.eclipse.org/r/141902 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=01d2391c4f95df250b36675d9660720c457233ac
(In reply to Eclipse Genie from comment #14) > Gerrit change https://git.eclipse.org/r/141902 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=01d2391c4f95df250b36675d9660720c457233ac > This causes a compile warning in our official build: https://download.eclipse.org/eclipse/downloads/drops4/I20190518-1800/compilelogs/plugins/org.eclipse.jdt.core.manipulation_1.11.200.v20190517-1818/@dot.html 1. WARNING in /common/org/eclipse/jdt/internal/ui/text/ChainFinder.java (at line 168) final LinkedList<ChainElement> chainCopy= (LinkedList<ChainElement>) chain.clone(); Type safety: Unchecked cast from Object to LinkedList<ChainElement> Please fix asap. We have M1 this Friday.
New Gerrit change created: https://git.eclipse.org/r/142413
Gerrit change https://git.eclipse.org/r/142413 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=be6d4a3df824aa30fd3a27d2b10dd3408f15b23b
Thanks, Roland, please add to N&N.
This needs to be reverted. It makes content assist very slow. At many places where I invoke content assist it takes very long and then brings a dialog that it took too long. And I get !ENTRY org.eclipse.jdt.ui 2 0 2019-05-20 14:44:33.289 !MESSAGE The 'org.eclipse.jdt.ui.org.eclipse.jdt.ui.javaCompletionProposalComputer.chain' proposal computer from the 'org.eclipse.jdt.ui' plug-in did not complete normally. The extension took too long to return from the 'computeCompletionProposals()' operation. Just one example: 1. Install I20190519-1800 2. Start with a new workspace 3. Import org.eclipse.jface from https://git.eclipse.org/c/platform/eclipse.platform.ui.git/ 4. Open ImageDescriptor at line 293 5. Insidde (ImageDataProvider) put the caret after "Image" 6. Ctrl+Space ==> takes very long and then aborts 7. In same file go to line 297 8. Put caret after "new I" 9. Ctrl+Space ==> takes very long and maybe aborts
NOTE: We have M3 this week.
(In reply to Dani Megert from comment #19) > Just one example: > 1. Install I20190519-1800 > 2. Start with a new workspace OK, I see that this is not true. It looks like in that recent build chain completion is disabled by default. However, in my big development workspace it *is* enabled. So, can it be that it was enabled by default at some point? If so, we have to make sure to disable it again, because it really makes content assist unusably slow in certain scenarios. Note that it is still enabled when cycling through the proposal computers using Ctrl+Space and when it comes to the chain completion it hangs as described.
> This needs to be reverted. Making sure it is disabled (also for those workspaces where it has been enabled before) would be sufficient for me.
I also think I'm facing this issue, although I didn't specifically enabled Chain completion. I see the pop-up about slow completion half of the time since I updated to latest snapshots; I didn't switch anything to turn chain completion on.
Not closely related but with a solution for Bug 544529 this delay would be less notable.
(In reply to Lars Vogel from comment #24) > Not closely related but with a solution for Bug 544529 this delay would be > less notable. Sorry, I mean Bug 538630
@Mickeal did you try to remove the chain completion from the cycling list as well. I experienced this weird behavior that the Proposal Computer is still called if we have that selected in the cycling list.
(In reply to Gayan Perera from comment #26) > @Mickeal did you try to remove the chain completion from the cycling list as > well. I experienced this weird behavior that the Proposal Computer is still > called if we have that selected in the cycling list. Initially, I didn't remove it at all. After my comment, I removed it from the 'default' proposal computers list and it's all fine. I can access it cycling and do not see any issue. I think at the moment, we need to make sure that the chain completion processor is not part of 'default' for the release, and try to improve things to enable it by default later when performance improve or when content assistant is made less blocking.
(In reply to Mickael Istria from comment #27) > (In reply to Gayan Perera from comment #26) > > @Mickeal did you try to remove the chain completion from the cycling list as > > well. I experienced this weird behavior that the Proposal Computer is still > > called if we have that selected in the cycling list. > > Initially, I didn't remove it at all. > After my comment, I removed it from the 'default' proposal computers list > and it's all fine. I can access it cycling and do not see any issue. > I think at the moment, we need to make sure that the chain completion > processor is not part of 'default' for the release, and try to improve > things to enable it by default later when performance improve or when > content assistant is made less blocking. Right! It looks like it was enabled at some point, then got disabled, but for those who used a build where it was enabled it stays enabled. So, must make sure it is definitely disabled and also not part of the cycling. Otherwise the feature must be removed and considered for 4.13.
(In reply to Dani Megert from comment #28) > (In reply to Mickael Istria from comment #27) > > (In reply to Gayan Perera from comment #26) > > > @Mickeal did you try to remove the chain completion from the cycling list as > > > well. I experienced this weird behavior that the Proposal Computer is still > > > called if we have that selected in the cycling list. > > > > Initially, I didn't remove it at all. > > After my comment, I removed it from the 'default' proposal computers list > > and it's all fine. I can access it cycling and do not see any issue. > > I think at the moment, we need to make sure that the chain completion > > processor is not part of 'default' for the release, and try to improve > > things to enable it by default later when performance improve or when > > content assistant is made less blocking. > Right! It looks like it was enabled at some point, then got disabled, but > for those who used a build where it was enabled it stays enabled. So, must > make sure it is definitely disabled and also not part of the cycling. > Otherwise the feature must be removed and considered for 4.13. I think if someone tried the feature in patchset 1 (from gerrit), they would end up with it enabled by default in their workspace but the feature submitted to master never enabled chain completion in the 'default' list. To disable it in the cycling list as well, we can add it to CODE_ASSIST_CATEGORY_ORDER with a cyclestate > 65535 . See https://git.eclipse.org/r/#/c/141902/2..3/org.eclipse.jdt.ui/ui/org/eclipse/jdt/ui/PreferenceConstants.java . In patchset 2 I had it completely disabled but after some discussion, it seemed to make sense to at least have it enabled for category cycling or it would not get usage/feedback at all.
Note : Profiling the relevant code, the performance issue is in TypeBindingAnalyzer.resolveBindingsForTypes(ICompilationUnit, IJavaElement []) from the ChainCompletionProposalComputer#findEntryPoints() call.
New Gerrit change created: https://git.eclipse.org/r/142469
Maybe it's worth adding a new and noteworthy entry for this?
(In reply to Roland Grunberg from comment #29) > I think if someone tried the feature in patchset 1 (from gerrit), they would > end up with it enabled by default in their workspace but the feature > submitted to master never enabled chain completion in the 'default' list. I never start(ed) my dev workspace with patched builds. So, the enabling must have happened otherwise.
(In reply to Eclipse Genie from comment #31) > New Gerrit change created: https://git.eclipse.org/r/142469 Please proceed with this asap. We have M3 this week.
Gerrit change https://git.eclipse.org/r/142469 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=aba5d7e4f7fd8b437f2239bc5dceb386565afc54
New Gerrit change created: https://git.eclipse.org/r/142629
Gerrit change https://git.eclipse.org/r/142629 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=b4db36bfb78c5ddd8f4026bd0924c256a851fc46
(In reply to Eclipse Genie from comment #37) > Gerrit change https://git.eclipse.org/r/142629 was merged to [master]. > Commit: > http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=b4db36bfb78c5ddd8f4026bd0924c256a851fc46 Released the uploaded patch for N&N entry. Please update if required.
Verified for 4.12 M3 using I20190522-0600 I can confirm that chain completion is disabled by default in both default list and content cycling list. I have a few improvements but we can discuss additonal ones on Bug 547502.
(In reply to Roland Grunberg from comment #39) > Verified for 4.12 M3 using I20190522-0600 > > I can confirm that chain completion is disabled by default in both default > list and content cycling list. I have a few improvements but we can discuss > additonal ones on Bug 547502. The fix seem to be incomplete (or we have a general problem with that preferences page), see bug 547833 comment 8. Users of 4.11 will get that new setting enabled in some cases *automatically*. This is very bad, because it can freeze Eclipse.
Reopening due bug 547833 comment 10. For 4.13 we should make sure we *can* contribute proposals disabled by default OR make this feature perfect and lightning fast, so it could be enabled by default :-)
(In reply to Andrey Loskutov from comment #41) > Reopening due bug 547833 comment 10. > > For 4.13 we should make sure we *can* contribute proposals disabled by > default OR make this feature perfect and lightning fast, so it could be > enabled by default :-) Or make content assists asynchronous, see Bug 531061.
(In reply to Lars Vogel from comment #42) > Or make content assists asynchronous, see Bug 531061. Asynchronous chain completion would only help, if it were separated into its own IContentAssistProcessor. Otherwise it would still block other JDT completions.
And still i think we need to solve the main issue and make the completion processor faster, may be we should have a different trigger for slow running completion like this like IntelliJ does. Shouldn't we try to use a more optimize index for searching chains. Chain search is more or less a predicated call hierarchy right ?
(In reply to Gayan Perera from comment #44) > And still i think we need to solve the main issue Yes.
(In reply to Andrey Loskutov from comment #40) > (In reply to Roland Grunberg from comment #39) > > Verified for 4.12 M3 using I20190522-0600 > > > > I can confirm that chain completion is disabled by default in both default > > list and content cycling list. I have a few improvements but we can discuss > > additonal ones on Bug 547502. > > The fix seem to be incomplete (or we have a general problem with that > preferences page), see bug 547833 comment 8. Users of 4.11 will get that new > setting enabled in some cases *automatically*. This is very bad, because it > can freeze Eclipse. I upgraded from 2019-03 to: Version: 2019-06 (4.12) Build id: I20190522-1800 ...and "Chain Template Proposals" was activated by default for default proposals. It made simple code completions 3-4 seconds slower. Disabling the option made it usable again.
Another observation, with "Chain Template Proposals" on, not only does it take 3-4 seconds before the assist popup becomes visible, but when it does, the GC collection meter goes crazy (ie, a ton of garbage is created). The Eclipse javaw process goes to 22% CPU use (one or two cores busy) for what seems to be an indefinite period (I let it run for a minute doing nothing, just leaving the popup open) until you close the assist popup.
(In reply to John Hendrikx from comment #46) > I upgraded from 2019-03 to: > > Version: 2019-06 (4.12) > Build id: I20190522-1800 > > ...and "Chain Template Proposals" was activated by default for default > proposals. It made simple code completions 3-4 seconds slower. Disabling > the option made it usable again. Please upgrade once again to 4.12 RC2, "Chain Template Proposals" will be gone now (see bug 547833).
New Gerrit change created: https://git.eclipse.org/r/144957
Would those interested care to try out chain completion again ? The performance issues should have been addressed with Bug 547502. You'll likely need to enable from Window -> Preferences. Java -> Editor -> Content Assist -> Advanced, and select 'Chain Template Proposals' under Content assist cycling.
(In reply to Roland Grunberg from comment #50) > Would those interested care to try out chain completion again ? The > performance issues should have been addressed with Bug 547502. > > You'll likely need to enable... Shouldn't we enable them by default, for the sake of consistency, since disabling doesn't always work anyway?
Roland's performance improvements made a great impact, but a regular 1s delay is still completely unacceptable to me. At the very least, I would recommend to port the preference GUI before reenabling. Or could chain completion learn to filter types triggering timeouts by itself?
Since all these better completions are inevitably high cost, could we not at least have a fast presentation of the easy completions with a "More" button to activate the expensive ones? Slow computation could start on a worker thread as soon as the easy completions are displayed. They might even be ready by the time the user has decided that "More" are wanted. Well actually the mechanism is already there; it's "Ctrl+Space" except the mechanism is broken. The preferences allows enabling of "proposal kinds" and "cycled pages", but does not allow the user to configure the relationship; in practice it is just a confusing duplication. It should be possible to have a first cycle page for fast Java, second page for slow Java, ... and of course a sub-menu to jump straight to e4 proposals even if e4 proposals are disabled. The preferences should offer a configuration of an eager/lazy worker thread rather than on/off.
@Ed i think we should aim for async completions, that will simplify the completions, also we could introduce a secondary key binding for known slow completions which are also async but takes a bit more time to provide the results. Like my implementation of smart sub types here https://github.com/gayanper/gap-eclipse-recommenders Also implementations of sync completion might be super easy and simple if we can bring in some reactive constructs into JDT. Not mandatory though.
async completion will certainly help but my impression is that e.g. chain completions will necessarily be slow, sometimes very slow and that 99.9% of the time I really do not want them, so I do not want a background thread slowing everything down, so I will disable them permanently and all your efforts are wasted for me. However on that 0.1% of the time when I do want them, I do not want to have to remember that I can go to the Java preferences, enable them (and remember to disable them again later). I want an easy, obvious option in the completion assist UI to start off some extra async computations. With on-demand slow activations we can maybe get rid of the horrible compromise that completion assist / type hierarchy is blind to types not directly on the classpath.
I'd like to re-visit enabling this feature for M3, and by "enabling", I mean having it show up as an option in the advanced content assist UI preference. From there users could decide to either : - Enable it as a separate completion category, accessible by cycling through to it (multiple ctr+space invocation) - Enable it in the "default completion category" (contributes on the first invocation of ctrl+space) It was disabled as a result of performance issues, but this has been improved so if there's no opposition, it should be in the preferences so that those who wish to use it have the ability to enable it and also help improve it. It can be tried out by applying https://git.eclipse.org/r/144957 .
Gerrit change https://git.eclipse.org/r/144957 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=010e27397bde27c4002b90eb490e31cf149ec12a
@Roland were you able to disable this processor by default ? Cause earlier it was enabled by default.
(In reply to Gayan Perera from comment #58) > @Roland were you able to disable this processor by default ? Cause earlier > it was enabled by default. The feature is disabled by default, but due to a separate bug (described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=547833#c9), any newly introduced category that is disabled by default gets ignored if the user has touched and saved any advanced code assist preference previously. I've filed this as Bug 550226. I've set the timeout for waiting for the computation to 1s so it should take no longer than that in the worst case. That can certainly be lowered if people feel that's a bit too high. The main reason for disablement was that it was taking far too much time for computation, so with that reduced it should be safe to have the feature in. With that said, I'm open to reverting if people feel this should still be a no-go.
@Roland what if we make the timeout a feature flag which can be toggled via system properties?
(In reply to Gayan Perera from comment #60) > @Roland what if we make the timeout a feature flag which can be toggled via > system properties? I didn't want to take this approach because the goal is to have the feature behaving reasonably without user tweaking. In the short term if the timeout is still not reasonable, then I'd prefer to get feedback and change the value. In the long term I could see providing options to allow users to tweak the number of chains returned, their min/max length, types to avoid looking into, and even timeout value once we've established sane defaults.
@Roland you have a point, lets keep it as it is.
@Roland, anything pending here for 4.13 or can it be closed?
N&N entry would be needed so I will create one before end of week.
New Gerrit change created: https://git.eclipse.org/r/148863
