Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[java] Unresolved target type for lambdas make overload resolution fail #5338

Closed
oowekyala opened this issue Nov 15, 2024 · 0 comments · Fixed by #5339
Closed

[java] Unresolved target type for lambdas make overload resolution fail #5338

oowekyala opened this issue Nov 15, 2024 · 0 comments · Fixed by #5339
Labels
in:type-resolution Affects the type resolution code
Milestone

Comments

@oowekyala
Copy link
Member

In the following UnusedPrivateMethod considers createListener unused if BytesParser is missing from the classpath. This is because when the target type for a lambda is unresolved (here the target type is BytesParser), we consider that the lambda does not match that type, as it is not a functional interface. I think when the target type is unresolved then we should assume it could be a functional interface that matches, and not fail the inference outright. This would allow createListener to resolve properly to its overload, even if eg the lambda parameter bytes would have an unknown type.


I encountered such an interesting situation: try check file BadClass.java

package com.semrush.siteaudit.crowly.kafka.component;

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.junit.jupiter.MockitoExtension;

import java.util.concurrent.CompletableFuture;

/**
 * Test.
 */
@ExtendWith(MockitoExtension.class)
class SomeTest {

    @Test
    void test() {
        final BytesListener listener = createListener(
            (bytes) -> CompletableFuture.completedFuture("HI!")
        );
        Assertions.assertNotNull(listener.onRecord(new byte[0]));
    }

    private static BytesListener createListener(
        BytesParser<String> parser
    ) {
        return bytes -> parser
            .parse(bytes)
            .thenAccept(System.out::println);
    }
}

OK - no issues, if there is a class BytesParser.java in ClassPath.

As soon as I delete the class BytesParser.java (argument type) thatUnusedPrivateMethod is triggered.

Avoid unused private methods such as 'createListener(BytesParser<String>)'

Removing the second class BytesListener.java (method return type) does not trigger the issue tUnusedPrivateMethod.

Why is it important for a static analyzer to have a neighbor class?

Originally posted by @deripas in #5184 (comment)

oowekyala added a commit to oowekyala/pmd that referenced this issue Nov 15, 2024
@oowekyala oowekyala added this to the 7.8.0 milestone Nov 15, 2024
@oowekyala oowekyala added the in:type-resolution Affects the type resolution code label Nov 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in:type-resolution Affects the type resolution code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant