[java] Fix incompatible class bounds not checked during incorporation

[jsotuyod]

Describe the PR

If an exception occurred during applicability testing it only means the candidate method is not applicable, not that an error actually occurred during inference, there is no need to abort altogether.

Related issues

• Fixes [java] Bad intersection, unrelated class types java.lang.Object[] and java.lang.Number #4980

Ready?

• Added unit tests for fixed bug/feature
• Passing all unit tests
• Complete build ./mvnw clean verify passes (checked automatically by github actions)
• Added (in-code) documentation (if needed)

[pmd-test]

	1 Message
📖	Compared to master: This changeset changes 0 violations, introduces 0 new violations, 7 new errors and 0 new configuration errors, removes 1 violations, 0 errors and 0 configuration errors. Download full report as build artifact
✅	Compared to master: This changeset changes 0 violations, introduces 0 new violations, 7 new errors and 0 new configuration errors, removes 1 violations, 0 errors and 0 configuration errors. Download full report as build artifact
✅	Compared to master: This changeset changes 0 violations, introduces 0 new violations, 0 new errors and 0 new configuration errors, removes 0 violations, 0 errors and 0 configuration errors. Download full report as build artifact
✅	Compared to master: This changeset changes 0 violations, introduces 0 new violations, 0 new errors and 0 new configuration errors, removes 0 violations, 0 errors and 0 configuration errors. Download full report as build artifact

Generated by 🚫 Danger

[oowekyala]

This is going to hide actual unexpected exceptions so I don't think we should fix this that way... My intuition is that we can catch that earlier and not need to create the bad intersection. Otherwise we should have a more specific exception type for this exception and only catch that one.

[jsotuyod]

My intuition is that we can catch that earlier and not need to create the bad intersection.

I don't see how we could do this… Assume our code is even a more adverse scenario:

public <T> T foo(T t) {
    return t;
}

public void bar() {
    Stream.of(foo("hello")); // should match Stream.of(T) by strict invocation
    Stream.of(foo(new Integer[] { 1, 2, 3 })); // should match Stream.of(T...) by strict invocation
}

Yes, we know the method is varargs, we know we are on a STRICT phase (not VARARGS), but we can't tell if the argument is or not an array until we try to resolve the context to figure out what foo(x) will return (and therefore hitting Lub).

Otherwise we should have a more specific exception type for this exception and only catch that one.

This is probably more reasonable…

[oowekyala]

I'm going to take a look with a debugger...

[oowekyala]

I think this should do the trick: oowekyala@6fea861

This is an incompatibility between bounds and should be checked like other bounds are checked, during incorporation.

I can't write to your branch so I just pushed into my repo.

[jsotuyod]

@oowekyala there you go, I incorporated those changes to my branch

[oowekyala]

LGTM

Edit: Actually there are some errors I am looking into. It would be nice if you made your branch writeable to maintainers @jsotuyod, there's a checkbox to tick somewhere

-> 5dcffca

[adangel]

@jsotuyod FYI, in case you didn't see the edit:

Edit: Actually there are some errors I am looking into. It would be nice if you made your
branch writeable to maintainers @jsotuyod, there's a checkbox to tick somewhere

-> 5dcffca

[jsotuyod]

@adangel no, Github disabled that for org-owned forks some time back… I'll have to switch my fork at some point.

[oowekyala]

I opened #4994 to continue this