[feature,navigation] Add support to bean navigation in spring projects

[gayanper]

There can be several type of navigation added, but most important navigation are

• Navigate from bean definition to injection candidates
• Navigate from a injection to it's bead definition.
  This can be easily achieved if we could index the required information, navigation information while we index the annotations. For example if a Inject annotation is processed we could keep the type of the field with it. Likewise we could keep the type for Bean annotation as well for example. Then when searching for a bean definition for a injection we could lookup our index for all subtypes which has the Bean annotation and which is a subtype of the field type which we want to find the bean definitions for :).

What do you all think about this feature ?

[martinlippert]

While I like the overall idea and agree that the case that you describe sounds easy and straight-forward, this is not as easy and straight-forward in practice unfortunately.

In the Spring Tools 4, we do two fundamentally different things:

• one is to allow super easy navigation based on what is in your source code, giving you better access of your code. This does not really interpret anything from your code and does not try to understand anything or guess what might happen at runtime, but instead provides a direct and plain view of your source code.
• the other thing is the live hover information, which shows exact and concrete bean wiring information from an app that runs and has certain beans being wired.

The feature you suggest is somewhere in the middle. It tries to understand and guess what might happen to bean wirings at runtime by looking at the source code only. This is super hard to get right, due to the dynamics of todays Spring applications (like conditions, dynamically generated beans, factories, etc.). In many cases, you can't easily find the exact bean wiring just from looking at the source - or it at least involves quite sophisticated mechanics to come as close as possible. The idea to check, for example, for subtypes (you mentioned that above), is, for example, quite expensive to realize. We did this in the previous generation of the Spring tools (STS3) and are trying to stay away from that for a good reason... :-) The list of bean definitions that we provide via symbols at the moment, for example, is also not really a complete list of beans that will appear in the app. It doesn't take factory beans into account in a correct way, it doesn't deal with dynamically generated beans, etc.

I like the distinction that the tooling makes with regards to the above mentioned design principles. Therefore I am a bit reluctant to dive into this feature request.

But I can clearly see the value on this. If we can find a simple way to help people navigate the source code that doesn't involve too much guesswork and heavy analysis, we can do something like this, but I don't a good idea for that in mind at the moment.

[gayanper]

@martinlippert Yes i agree with you, if we try to provide navigation based on what we find in source, the users might take is granted that its how the application going to be wired in runtime. But for things which are straight forward like Named Qualified injections may be we might be able to have easy navigation. Then may be we should try to identify and only provide static navigation for such beans. That might also confuse the users, why its only available for certain type but not all. Will it be a good idea to look at IntelliJ spring implementation and see if we can take some feature in here ? I would also like to here what community members thinks about this as well.

[kdvolder]

As far as I know IntelliJ 'spring model' implementation is proprietary and not open-sourced. So you can't really look at it.

[gayanper]

As far as I know IntelliJ 'spring model' implementation is proprietary and not open-sourced. So you can't really look at it.

True but may be we can look at the functionality. They offer the 30 days trial to try out, and there might be members who has paid license who can pitch in as well. Because these features will benefit vscode as well isn't it ?

[martinlippert]

@gayanper I am not a big fan of looking at IntelliJ (or any other tool) and re-implement the features. There are many super awesome features in the IntelliJ support for Spring, but there are also many features that people don't like, find annoying, etc. Therefore I don't think looking at another tool and doing the same is the right approach here.

With Spring Tools 4, we've chosen a different approach and a different route to move forward. We took the chance of a fresh start to also re-thing existing features and imagine new, maybe more powerful ways of supporting developers using Spring. A good starting point for me is always to understand the needs first, the use cases, the situations where something is difficult or tedious - and then think about a way to help in those situations. Come on, lets be more creative and innovative than copying old features from existing tools out there.

I am sure we can do the same for this enhancement request. Let's collect a few examples (in code) where navigation would help and then let's try to imagine a simple way of supporting this.

@Qualifier might be a good starting point here. Let's see if we can find some real world examples where @Qualifier is used and see what the underlying issue is.

As an additional note: we have this navigation and detailed information support for bean wirings using live data from the running app. Do you really think we need more or less the same feature based on source-code only? I would assume that people could easily start the app (or they have it running anyway for trying it out) and get the exact information. I am sure this work for every case, but what are those cases for which this approach doesn't work? Again, just trying to understand the issues first.

[gayanper]

@martinlippert totally agree with your points :) thanks for clear things out as well.

As an additional note: we have this navigation and detailed information support for bean wirings using live data from the running app. Do you really think we need more or less the same feature based on source-code only? I would assume that people could easily start the app (or they have it running anyway for trying it out) and get the exact information. I am sure this work for every case, but what are those cases for which this approach doesn't work? Again, just trying to understand the issues first.

Well i have scenario where i work with a monolith application which uses spring and which is deployed inside jboss. i work with these modules every day. So running the app and looking at the injections is not a option to me because i cannot use the actuators. Most of the beans are autowired based on types or names. So if some navigation support is there that would be really good. But out symbol view can serve the same thing since we have all the information there as well (with the new enhancement i'm working for Injection and Resource annotation). The feature i'm expecting here is going a step further the link the information we already know. But i know the symbol information cannot be used for such thing. So we might need to think of a better way to provide that information from LSP. Lets try to think fresh, may be i should finish my enhancement and try with my projects to see if i need further navigation support as a developer as well :).

[martinlippert]

@gayanper Please note that we introduced a way to get live bean wiring information for regular non-Boot Spring projects when they are running: https://github.com/spring-projects/sts4/wiki/Live-Application-Information#application-requirements-for-non-boot-spring-projects-new-in-411

Would you like to try that and see if that already helps a bit? And if something is not working as expected, report an issue for this feature?