search

eclipse-jdt / eclipse.jdt.ui

Eclipse Public License 2.0
37 stars 92 forks source link

Code Minings - Method call occurences for common named methods are not correctly calculated #370

Closed CarlosMOGoncalves closed 1 year ago

CarlosMOGoncalves commented 1 year ago

Description

Hello there,

I noticed Code Minings is not calculating correct occurences of, at least, methods. This has likely something to do with the way occurences are found. I don't know when it started working like this.

Expected Outcome

I expect that an occurence of a method call is calculated in the same way as "Open Call Hierarchy" option or at least that shows the call occurences in the workspace.

Current Outcome

Some methods, depending on their name and/or signature will be marked has having "X occurences" but these don't match any actual call of that method, but rather any other method with the same name that can be somehow found in the classpath.

Steps to reproduce

I have prepared a sample application that has a very simple Payara Micro application, whose kind is irrelevant to the case in point. It can be found here

This app does nothing special. It has a Jakarta REST endpoint but that is just for show.

  1. Fresh install Eclipse for Eclipse IDE for Enterprise Java and Web Developers 2022-12
  2. Checkout the project from my repository
  3. Run mvn clean install on it
  4. Activate Code Minings for method references, like this:

image

  1. Then navigate to the class NumericUtils.java, method getType():

image

  1. It marks 1 occurence. However, that occurence is not correct, but rather just an occurence a similarly named method on a comment:

image

  1. If we use "Open Call Hierarchy" on that method we clearly see that no one is calling it:

image

  1. The same can be said for methods with common names, like on TestResource#get():

image

  1. Which is not in fact the right callee:

image

Final note

Environment

humphreygao commented 1 year ago

image check this option may solve this problem.

I expect that an occurence of a method call is calculated in the same way as "Open Call Hierarchy" option or at least that shows the call occurences in the workspace.

I agree.

CarlosMOGoncalves commented 1 year ago

Hello @humphreygao,

Thanks for the quick reply. Indeed, this prevents those results to be counted as matches. Solves it, basically.

However, I think this brings up the point: should these kind of "potential matches" be considered in Code Minings? Because I think Code Minings is extremely useful for quick checking references to methods (and types, fields), specially to quickly understand and consider dependencies... but these results must be very accurate or they risk losing their value.

Surely, showing potential matches, by default, is not what is expected and potentially highly misleading.

Here's an example. This is a screenshot from a somewhat more complex project I have. There is a JPA entity that has a method called getType(), similar to the one in the issue description. On Code Minings this shows 123 references (!!!), but most of those are in fact from 3rd party libraries which my project depend on which naturally cannot be referencing my project. Check below:

image

The actual expected results for this Code Mining is rather this (now with potential matches disabled):

image

All of these references are actually in my own project, which is what is correct and expected.

What do the developers think about this? Wouldn't it be much more accurate to perform the Code Minings default reference search withous "potential matches"?

humphreygao commented 1 year ago

What do the developers think about this? Wouldn't it be much more accurate to perform the Code Minings default reference search withous "potential matches"?

Could ask @angelozerr as he is the original developer of code mining https://github.com/angelozerr/jdt-codemining

humphreygao commented 1 year ago

@jdneo 在写代码时，Eclipse的codelens跳来跳去的，处于几乎不可用状态，但是VS Code就好多了，是怎么做到的？

jdneo commented 1 year ago

@humphreygao VS Code has a dedicated job for document update. When trying to resolve the code lens, we will first wait the document update job is finished.

Take the debugger's Run | Debug code lens as an example: https://github.com/microsoft/java-debug/blob/42f9ac7d4843b75b1fdde64762d8c5ce4a4c51b2/com.microsoft.java.debug.plugin/src/main/java/com/microsoft/java/debug/plugin/internal/ResolveMainMethodHandler.java#L51-L55

jjohnstn commented 1 year ago

| What do the developers think about this? | Wouldn't it be much more accurate to perform the Code Minings default reference search withous "potential matches"?

I think this could be accomplished by adding a specific option to the Code Minings preferences and not rely on the Search settings which are in another preference page which is unintuitive. This option could be set to Ignore by default. What do you think?

CarlosMOGoncalves commented 1 year ago

Hello @jjohnstn ,

Those are my thoughts exactly. As a user I think this would definitely be more intuitive. All functionality related to Code Minings should be inside the Code Minings preferences.

A lot can be said about the sheer amout of Preferences in Eclipse out of the box, with a lot of them being really hard to find, some being contraditory and a lot of overlapping.

But this particular case is one that would really benefit from not relying on other settings.

Thanks @jjohnstn