Community
Participate
Working Groups
I upgraded to M3 yesterday, builds and tssts seemd ok. Today deugging / editing is a disaster. 2019-03 had some form of PDE completion proposal hang that was really irritating but just tolerable. This has now got much worse. Close to unuseable. Reverting to 2019-03. One error log is: 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. One UI hang is: Stack Trace at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:11890) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:12352) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.parseStatements(MethodDeclaration.java:198) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.parseMethods(TypeDeclaration.java:951) at org.eclipse.jdt.internal.compiler.parser.Parser.getMethodBodies(Parser.java:11036) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:878) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:909) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:614) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:832) at org.eclipse.jdt.core.dom.ASTParser.createBindings(ASTParser.java:1075) at org.eclipse.jdt.internal.ui.text.TypeBindingAnalyzer.resolveBindingsForTypes(TypeBindingAnalyzer.java:357) at org.eclipse.jdt.internal.ui.text.TypeBindingAnalyzer.getTypeBindingFrom(TypeBindingAnalyzer.java:267) at org.eclipse.jdt.internal.ui.text.TypeBindingAnalyzer.findFieldsAndMethods(TypeBindingAnalyzer.java:100) at org.eclipse.jdt.internal.ui.text.TypeBindingAnalyzer.findVisibleInstanceFieldsAndRelevantInstanceMethods(TypeBindingAnalyzer.java:86) at org.eclipse.jdt.internal.ui.text.ChainFinder.findAllFieldsAndMethods(ChainFinder.java:146) at org.eclipse.jdt.internal.ui.text.ChainFinder.searchDeeper(ChainFinder.java:132) at org.eclipse.jdt.internal.ui.text.ChainFinder.searchChainsForExpectedType(ChainFinder.java:81) at org.eclipse.jdt.internal.ui.text.ChainFinder.startChainSearch(ChainFinder.java:58) at org.eclipse.jdt.internal.ui.text.java.ChainCompletionProposalComputer.lambda$0(ChainCompletionProposalComputer.java:158) at org.eclipse.jdt.internal.ui.text.java.ChainCompletionProposalComputer$$Lambda$836/1181573674.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
Ed, did you had "Chain Template Proposals" enabled? This one should be *in theory* disabled by default (Preferences -> Java -> Editor -> Content Assist -> Advanced). Please make sure it is disabled and try again. If the problem reoccurs, please provide your error log.
See bug 544108 comment 39.
After reverting to 2019-03 I get a some content proposals have been uninstalled. I took the restore defaults path. Back to useable. Looks as if an addition for 2019-06 is not yet ready for prime time. (In reply to Andrey Loskutov from comment #1) > Ed, did you had "Chain Template Proposals" enabled? No idea if enabled or not and no idea what they might be. I certainly didn't adjust any setting. I just changed my 4.11 shortcut to 4.12M3 and started on the new release with the old workspace; just as I normally do.
(In reply to Ed Willink from comment #3) > (In reply to Andrey Loskutov from comment #1) > > Ed, did you had "Chain Template Proposals" enabled? > > No idea if enabled or not and no idea what they might be. I certainly didn't > adjust any setting. I just changed my 4.11 shortcut to 4.12M3 and started on > the new release with the old workspace; just as I normally do. Ed, as said, please check this under Preferences -> Java -> Editor -> Content Assist -> Advanced.
(In reply to Andrey Loskutov from comment #4) > Ed, as said, please check this under Preferences -> Java -> Editor -> > Content Assist -> Advanced. Changing to 4.12M3 again and comparing the 4.12M3 and 4.11 dialog, the only difference I see is a not-checked Chain Template Proposals in both selection panes. 4.12M3 completion assist now seems reasonable. If I explicitly select Chain Template Proposals, completion assist renders editing unuseable again. So yes, it looks like the new Chain Template Proposals is not fit for prime time, so we have two problems. a) Why do Chain Template Proposals make editing unuseable b) why was Chain Template Proposals functionality enabled by an upgrade that just re-used an old workspace on a new installation?
We could even consider this critical or even blocker.
Perhaps my usage was not as anticipated. Having looked at the documentation, it is all based on completion i.e. ... = $ } where $ is the completion point at the end of something plausible with a } to give a clear context. I was doing something like: System.out.println(projectMap.getClass().getSimpleName() + "-" + projectMap.$instanceCount + ": install EPackageDescriptor-" + instanceCount + " for '" + uri + "'"); to investigate available names. But the expected type is String and so there are of course gazillions of possibilities. I thing I also tried where the expected type is Class. Similarly I find Completion Assist really bad for 're-completion' e.g. at xxx.yyy$aaa(zzz) then selecting yyybbb(...) from the offerings always leaves me with at least the syntax error xxx.yyybbb(args)(zzz) and sometimes xxx.yyybbbaaa(bbbargs)aaa(zzz) Has in-place re-completion not been considered?
(In reply to Dani Megert from comment #6) > We could even consider this critical or even blocker. I can't reproduce with a fresh 4.11 workspace and all default settings. BUT. I can reproduce with a fresh 4.11 workspace where I first select *everything* in any table on the Preferences -> Java -> Editor -> Content Assist -> Advanced dialog. Using *that* workspace with 4.12 I see that again, all values in this table (except "Java Type Proposals" and "Java Non-Type Proposals") are selected, *including* "Chain Template Proposals". Note: looks like "Java Type Proposals" and "Java Non-Type Proposals" saving is broken - once enabled, they show up enabled during the same session, but after restart they are always disabled. I'm not sure if this expected and some strange feature???
(In reply to Andrey Loskutov from comment #8) > I can reproduce with a fresh 4.11 workspace where I first select > *everything* in any table on the Preferences -> Java -> Editor -> Content > Assist -> Advanced dialog. Using *that* workspace with 4.12 I see that > again, all values in this table (except "Java Type Proposals" and "Java > Non-Type Proposals") are selected, *including* "Chain Template Proposals". OK. Looking on the code, it is enough to change *something* in the JDT codeassist preferences, so that the preference value is changed and persisted - as soon as the PreferenceConstants.CODEASSIST_EXCLUDED_CATEGORIES value is persisted, defaults for exclusion do not work anymore - and so *any* new proposal introduced as "excluded by default" is NOT excluded by default. The entire concept is not working here. We need to know *both* user included and excluded categories, so that for values not existing in the both lists defaults could be applied. > Note: looks like "Java Type Proposals" and "Java Non-Type Proposals" saving > is broken - once enabled, they show up enabled during the same session, but > after restart they are always disabled. I'm not sure if this expected and > some strange feature??? This seem to be a side effect of the fix for bug 250629, which is a bug but unrelated to the current problem.
(In reply to Andrey Loskutov from comment #9) > OK. Looking on the code, it is enough to change *something* in the JDT > codeassist preferences, so that the preference value is changed and > persisted - as soon as the > PreferenceConstants.CODEASSIST_EXCLUDED_CATEGORIES value is persisted, > defaults for exclusion do not work anymore - and so *any* new proposal > introduced as "excluded by default" is NOT excluded by default. I think we have two choices: remove the feature from 4.12 (probably we can simply comment out plugin.xml contribution) or introduce a quick and dirty hack in org.eclipse.jdt.ui.PreferenceConstants.initializeDefaultValues(IPreferenceStore) to check if we have started 4.12 for the first time and if that is the case, re-write user value of PreferenceConstants.CODEASSIST_EXCLUDED_CATEGORIES to the ${user value} + org.eclipse.jdt.ui.javaChainProposalCategory. Looking on the current issues with the new proposal, and with the problem that the hack will need to be left *forever* in the code, I would vote for "hiding" the new feature from 4.12. I will push a patch in a moment. I think we can't risk to break content assist for Java so badly, this will be not acceptable for our users. > The entire concept is not working here. We need to know *both* user included > and excluded categories, so that for values not existing in the both lists > defaults could be applied. This need to be done after 4.12, the change will require more rework as allowed for 4.12.
New Gerrit change created: https://git.eclipse.org/r/143167
(In reply to Ed Willink from comment #5) > Changing to 4.12M3 again My workspace has been backwards and forwards across many tens, possibly hundreds, of Eclipse releases in the last 4 years.
Just a small side issue: (In reply to Ed Willink from comment #7) > Has in-place re-completion not been considered? Please see the first radio buttons below Preferences > Java > Editor > Content Assist > Insertion By default you can let completion overwrite by pressing Ctrl+Return instead of plain Return.
(In reply to Andrey Loskutov from comment #10) > (In reply to Andrey Loskutov from comment #9) > > OK. Looking on the code, it is enough to change *something* in the JDT > > codeassist preferences, so that the preference value is changed and > > persisted - as soon as the > > PreferenceConstants.CODEASSIST_EXCLUDED_CATEGORIES value is persisted, > > defaults for exclusion do not work anymore - and so *any* new proposal > > introduced as "excluded by default" is NOT excluded by default. > > I think we have two choices: remove the feature from 4.12 (probably we can > simply comment out plugin.xml contribution) or introduce a quick and dirty > hack in > org.eclipse.jdt.ui.PreferenceConstants.initializeDefaultValues(IPreferenceStore) > to check if we have started 4.12 for the first time and if that is the case, > re-write user value of PreferenceConstants.CODEASSIST_EXCLUDED_CATEGORIES to > the ${user value} + org.eclipse.jdt.ui.javaChainProposalCategory. > > Looking on the current issues with the new proposal, and with the problem > that the hack will need to be left *forever* in the code, I would vote for > "hiding" the new feature from 4.12. I will push a patch in a moment. I think > we can't risk to break content assist for Java so badly, this will be not > acceptable for our users. > > > The entire concept is not working here. We need to know *both* user included > > and excluded categories, so that for values not existing in the both lists > > defaults could be applied. > > This need to be done after 4.12, the change will require more rework as > allowed for 4.12. +1. It's not just content assist itself, but it will also make people not use/try chain completion in the future.
Please see my comment in the Gerrit change. You need to test what happens for users that have it already enabled, either by accident or explicitly.
(In reply to Dani Megert from comment #15) > Please see my comment in the Gerrit change. You need to test what happens > for users that have it already enabled, either by accident or explicitly. To keep this on the bug: The user will see *once* a dialog: "Content Assist Problem" - "Some content proposal kinds have been uninstalled. It is recommended to review content assist settings" - <Link to settings> / <Restore Default> |<Close>. Neither "Close" not "Restore Defaults" do anything bad, also after restart. The dialog shows up on first content assist invocation, the code in org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerRegistry.updateUninstalledComputerCount() notices that the remembered number of proposals doesn't match and later dialog is shown. So from my POV, this is works as expected.
I feel that the philosophy has gone wrong. It is inevitable that cleverer and cleverer completion computations will make Eclipse slower and slower for proposals that have lower and lower probability of utility. Give the user control. No cost by default, incur the cost on demand. There is also a naive assumption that the completion proposal computation knows what to do, which for chains implies an ability to empathize the target type. What if the code is rubbish. How do I search for a chain then? Either I create a dummy target variable, or better give me a dialog. For smart proposals, let there be a Smart Quick Fix dialog, where I can tunnel down to chains and configure its target type, overriding the deduced type if needed, and enabling interface-2-implementation cast on traversals if I want insight into what might be possible with actual types. The cycling through pages of proposals was ok for 2 perhaps 3 alternatives. I never look at the extra pages since they never seem to achieve anything apart from confusing me when some how one has been selected. It just does not scale for 8 or more... Trees are better.
New Gerrit change created: https://git.eclipse.org/r/143204
Gerrit change https://git.eclipse.org/r/143167 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=8a790a3a6a7b9b6288650993cb82a37025e05cfa
Gerrit change https://git.eclipse.org/r/143204 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=cc01dc73ced96e6bc7586a3845a4e2a91a806d3b
Disabled contribution and removed N&N. Will re-open & re-target 544108. Will close after the patch is available for validation.
Verified with I20190603-1800 that chain completion is not available.