STS on Eclipse: quick fix for "unknown property" always shows just "Computing..." on first invocation

[mauromol]

Describe the bug
When you enter a new unknown property in application.properties, a warning shows up saying it's an unknown property. Using quick fix (Ctrl+1) you should be able to create the corresponding metadata in additional-spring-configuration-metadata.json file.
However, the very first time you invoke Ctrl+1 on a specific property, only "Computing..." is shown and it is never replaced with the actual quick assist action.

To Reproduce
Open application.properties.
Add a new property like: foobar.enabled=true.
foobar.enabled gets underlined in yellow; do not hit F2 or wait for explanation tooltip to show up
Quickly place the cursor within foobar.enabled name and hit Ctrl+1.

Please note: if you wait enough for the rendering of the tooltip explaining that the property is unknown to be shown, then you probably won't hit this bug. Perhaps, if you have a super-fast system you won't hit it either, but on my system, unless I wait for every tooltip to show up, I will certainly have to hit Ctrl+1 twice for each property in order to trigger the requested action.

[martinlippert]

I think this is closely related to #579 and most likely caused by some internal mechanism inside of the language server blocking it, so that the client waits a very long time before getting an answer for this quick fix proposals.

For #579, I re-worked quite a huge part of the way the language server reacts to those messages and removed a lot of situations where this blocking could have happened. Therefore I will close this issue here as well - as fixed for the upcoming 4.10.0.RELEASE.

If you want to give it a quick try, feel free to try the latest CI builds from here:
http://dist.springsource.com/snapshot/STS4/nightly-distributions.html

If this still happens, please capture a thread dump of the IDE process as well as the Spring Boot language server process while this takes so long to show up the warning and the quickfix and we can re-open this issue here.

[mauromol]

Hi Martin,
indeed this was not really a problem of "I have to wait a very long time", but rather one in which the first invocation did never produce the expected proposals. Anyway, I will try to test the new version as soon as possible, although, to be honest, it's not that easy because with STS4 you tend to "deprecate" old Eclipse versions too quickly... I see that there are nightly update sites for 2020-12 and 2021-03, but I'm still on 2020-09 :-(
Please consider giving users some more time to update their Eclipse base system...

[martinlippert]

@mauromol The usual policy that we follow is to ship a release on the latest Eclipse release and provide a separate update repo for the previous Eclipse release. Therefore the Spring Tools for Eclipse 4.10.0 release will be based on Eclipse 2021-03 and the separate update repo will be around for the Eclipse 2020-12 release.

The main p2 repo that Spring Tools 4 for Eclipse distributions use always point at the latest Spring Tools 4 release as well as the latest Eclipse release, so that automatic updates will update your installation to the latest Spring Tools release as well as the latest Eclipse release - so I hope that most of the Spring Tools users are always on the latest Eclipse release.

Nevertheless, you asked for a separate p2 update repository for Eclipse 2020-09, so I enabled those compatibility builds again and you will find that p2 repo on the mentioned nightly CI update download page again. And I will build that for the upcoming 4.10.0 release as well. Hope that helps you and makes the update path more convenient... :-)

[mauromol]

Hi Martin,
first of all, I would like to thank you very much for you kindness. The issue with so frequent Eclipse updates is that, although at the Eclipse Foundation they say that major upgrades from one version to the other are seamless, in my experience it's not actually true.
I talked a bit about this with Mikael Istria some time ago. First of all, in place updates of the Eclipse Runtime Platform substantially should work, but they are not officially supported. Workspace upgrades are handled, but creating new workspaces is recommended. In any case, upgrading Eclipse for me means downloading a new Runtime Platform, running it, installing a bunch of third-party Eclipse plugins on it (hoping they have been built and/or adapted for the new version or at least sufficiently tested) and sometimes re-creating my workspaces. This requires some work. Even more importantly, this is some work that is to be performed by all the team members. Being forced to upgrade every 3 months, because this is the current fashion, is crazy IMHO.
This is even worse on Linux: new Eclipse versions tend to drop official support even for still supported Linux distributions very fast. Last year, after upgrading from one Eclipse version to the other (with no suspect release notes that could warn me about this) I found my system unable to run Eclipse any more because they increased the minimum required version for GTK3, so my Ubuntu 16.04-based system (still supported at that time - indeed it is until April this year) was not able to run native Eclipse any more. Even worse, Ubuntu 18.04 (the next LTS release) was already NOT OFFICIALLY SUPPORTED BY ECLIPSE ANY MORE, being 20.04 just released (we are talking about Eclispe 2020-06... Ubuntu 20.04 had been released just a couple of months before and Ubuntu 18.04 is supported by Canonical until April 2023...). The only option for me was to try the Flatpack version (https://flathub.org/apps/details/org.eclipse.Java), which most works, but still has some huge drawbacks and I couldn't see any official commitment from the Eclipse Foundation (it seems like there's just one Red Hat guy that cares about it and he can't do miracles alone). For instance, any plugin that requires access to native code (luke Subclipse with JavaHL connectors) has issues because of the sandboxing mechanism (see flathub/org.eclipse.Java#15) and Spring Boot seems not to work properly in debug mode because of how installed JREs are handled with regards to symlinks (see flathub/org.eclipse.Java#18 and flathub/org.eclipse.Java#5 for instance). These are serious problems, in addition to some other smaller nuisances, in particular flathub/org.eclipse.Java#12, which is about updates (once again...) which, by the way, are usually performed automatically by the operating system and can break your environment from one day to the other, so I gave up with Flatpack in the end, and I was forced to prematurely upgrade my operating system to Ubuntu 20.04.

This long story just to tell you that: it's really annoying being forced to upgrade your development environment with a so fast pace and I really hope that you could take into consideration the option to give users at least two older releases support for your STS Eclipse base. I don't know how much work it is for you :-(

This said, I tested your nightly and this is what I see. When I start to type a new property in application.properties, now the content assist proposal shows up instantly. It shows "Computing proposals (0%)" which then closes quickly (by the way, the completion ratio remains at 0%):

If suggestions exist, a new popup will show up and list all the possible known properties. If no property is known which matches your input (like in the example above, where I typed some bogus characters) no new popup is shown and hitting Ctrl+Space seems to do nothing. This is a bit inconsistent with Eclipse content assist experience in general, which will always fire a popup with possibly a "No XXX proposals" message if no suggestions are available.

But going back to my original issue: if I hit Ctrl+1 on an uknown property I see two different behaviours:

• sometimes it works just like before: two popups with "Computing..." show up and they don't go away. Proposals to add metadata do not show, I must close that popup and invoke Ctrl+1 a second time
• sometimes nothing happens (i.e.: Ctrl+1 totally broken)

I could even capture a case in which "Computing" is shown twice:

By the way, I have many errors like this in my Eclipse log, perhaps they are related?

eclipse.buildId=4.17.0.I20200902-1800
java.version=11.0.10
java.vendor=Ubuntu
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=it_IT
Command-line arguments:  -data file:/home/mauro/workspace/rolling/DCS-POST-trunk/ -os linux -ws gtk -arch x86_64

org.springframework.tooling.ls.eclipse.commons
Error
Mon Mar 08 10:00:15 CET 2021


Java Model Exception: Java Model Status [Character.class [in java.lang [in <module:java.base>]] does not exist]
	at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:575)
	at org.eclipse.jdt.internal.codeassist.SelectionEngine.selectType(SelectionEngine.java:1598)
	at org.eclipse.jdt.internal.core.NamedMember.resolveType(NamedMember.java:328)
	at org.eclipse.jdt.internal.core.NamedMember.resolveType(NamedMember.java:270)
	at org.springframework.tooling.jdt.ls.commons.java.JavaData.resolveFQName(JavaData.java:520)
	at org.springframework.tooling.jdt.ls.commons.java.JavaData.fillAnnotationData(JavaData.java:370)
	at org.springframework.tooling.jdt.ls.commons.java.JavaData.createAnnotationData(JavaData.java:362)
	at org.springframework.tooling.jdt.ls.commons.java.JavaData.createMethodData(JavaData.java:250)
	at org.springframework.tooling.jdt.ls.commons.java.JavaData.fillTypeData(JavaData.java:314)
	at org.springframework.tooling.jdt.ls.commons.java.JavaData.createTypeData(JavaData.java:276)
	at org.springframework.tooling.jdt.ls.commons.java.JavaData.typeData(JavaData.java:69)
	at org.springframework.tooling.ls.eclipse.commons.STS4LanguageClientImpl.lambda$15(STS4LanguageClientImpl.java:454)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)

I can't understand the nature of these log entries, I'm regularly running Eclipse with an OpenJDK 11 which is working fine... I never saw these errors before performing the upgrade to STS 4.10 nightly this morning...

[martinlippert]

Your detailed explanation of your update story is much appreciated and I understand the efforts and pain that is involved here. As a consequence, I will keep the Eclipse 2020-09-based builds running for the upcoming release and afterwards will keep the builds for 2020-12 running for the next release (so having builds for the latest Eclipse release, the one before, and the one before that).

Did you see https://gist.github.com/martinlippert/5155155 ? Maybe that helps you installing third-party plugins more easily into a new installation. At least you can script it that any and don't need to use the UI manually.

With regards to the problem with the content-assist and the quick fixes: Can you capture a thread dump of the IDE process as well as the spring-boot-language-server process while the content-assist seems to wait for proposals and attach them here? That would be great.

Also it would be good to enable the log output of the Spring Boot Language Server in the Preferences -> Language Servers -> Spring Language Server and then enable the checkbox for Spring Boot. This will redirect the log output of the spring boot language server process to a console tab in your IDE. Would be great if you could keep that open while reproducing the content-assist / quick fix issues and attach that output here as well.

Thanks a lot for your help and detailed reports, much appreciated.

[mauromol]

Hi Martin,
just tried it: in the Language Server console nothing gets printed when the "Computing..." popup opens and remains still. Please note I'm sure logging is working fine because it gets crowded with entries when I try code assist or hovers, for instance. Simply, nothing gets printed when hitting Ctrl+1 and the mentioned popup window shows up. After all, nothing gets printed to that console even when Ctrl+1 is working fine (i.e.: the second time I type it after the first unsuccessful attempt).

I may try to take thread dumps, my only fear is that I won't capture anything. Indeed, the IDE does not seem to be stuck at doing some lengthy computation: IMHO it's just a problem of updating that "Computing..." message with the result of the computed quick assist options. It seems like just an UI update problem: Ctrl+1 is invoked, options to be shown in the popup dialog are not yet been computed, so "Computing..." is shown; when computation has ended, that popup window should be updated so that the "Computing..." message is replaced with the available Quick Assist options, however no update is performed and the "Computing... " message remains stuck.

Or, as an alternative, proposals should be computed synchronously and the popup should appear only after the proposals are ready: this would cause the UI thread to be frozen for a moment, but since this computation is indeed extremely quick I don't think it would hurt so much the user experience. Of course, a working asynch solution would be better though.

[martinlippert]

If this turns out to be an issue with the underlying completion dialog of the generic editor, we will have to report this for the LSP4E or the platform at Eclipse, but let me first try to investigate this in a bit more detail.

[martinlippert]

This looks like an issue with the marker resolution mechanism of the LSP4E project, so I filed this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=571827

Not sure yet how to solve this, but at least I have an idea about what is going wrong here... :-) And indeed we don't need a thread dump of the language server process - which seems to work just fine here.

[martinlippert]

This has been fixed a while ago in LSP4E and the fixed version is also included in the recent Spring Tools releases. Therefore closing this one here.