[BUG] Java provider rules not triggering for patterns ending with * or (*)

[joe-braley]

sample1.zip

Is there an existing issue for this?

• I have searched the existing issues

Konveyor version

v0.6.0-alpha.2

Priority

Major

Current Behavior

Hi team!

I have created sample Java files to test analysis against. When running assessments, we noticed rules with patterns ending in * or (*) are not triggering. This results in missing issues in the generated static report.

For the attempt I have run for this issue the command I ran was:
./kantra analyze --input ./sample1/ --target azure-appservice --output ./sample1-output --overwrite

I believe on the sample code, which is attached, this app-service rule should have triggered and added an incident in the static report. However, I only observe a single rule being triggered with respect to Windows style pathing in the code.

Please let me know if I performed any steps/categorized incorrectly! This is my first issue in this repo 😄

Expected Behavior

The rule linked above would trigger and additional incidents would appear in the static report.

How Reproducible

Always (Default)

Steps To Reproduce

1. Download the sample Java code attached to this issue.
2. When running an assessment, set the target to azure-appservice.
3. Execute the assessment.
4. Observe that the rule "09-eap-to-azure-appservice-environment-variables.windup.yaml" with the following patterns did not return results:
   • java.referenced:
     location: METHOD_CALL
     pattern: java.lang.System.getenv(*)
   • java.referenced:
     location: METHOD_CALL
     pattern: java.lang.System.getProperty(*)

Environment

version: v0.6.0-alpha.2
SHA: 2f22d6db9f4ed5e64ba211af082fd8e9de9b7e01
image: quay.io/konveyor/kantra

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian

Python 3.11.2
Java 17.0.13+11

Anything else?

The result of the latest analysis on the attached sample I performed using the above Kantra version. Yields only one issue:

This view is to show the sample code with the Java function calls. I believe we should see more issues when these are present in the code.

[konveyor-ci-bot]

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members.

[joe-braley]

CC @kthatipally

[jmle]

I have been taking a quick look at this and it seems that there is a problem when matching method calls in general. We will need to take a deeper look into it.

[jmle]

I have discovered some things after investigating. Having a System.getenv() call in the code:

• getenv and getenv() both work.
• getenv* also works
• When having methods with argument types (for instance, rest.getForObject(new URI("http://www.example.com/"), Source.class);), the following works: getForObject(*,*) and getForObject(URI,Class<Source>) The following does not: getForObject(*).
• Qualifying the method in the previous example works, ie looking for org.springframework.web.client.RestTemplate.getForObject, but having System.getenv() in the code and looking for java.lang.System.getenv does not.

My conclusions after this:

• There seems to be a problem when trying to look for static method calls in the LS. I am not sure what's causing this. A potential fix would be to change these rules to an and condition requiring both the call getenv and the class System to be used in the same file. More needs to be investigating, maybe trying to contact the Eclipse people.
• The (*) pattern only works if there is a single argument to the method, otherwise it doesn't. There must be as many * as arguments in the method. Some rules may need a fix.

FYI @rromannissen @dymurray

[shawn-hurley]

I wonder if for method searches it makes sense to remove the arguments if there is a (*) assuming that the rules want to find all overloaded methods.

As for the static functions, I do wonder if there is a special parameter that we have to add in the search to consider these?

[zhoufenqin]

it seems that the issue still exist, is there any plan to fix it?