OCP Doubt: Ambiguous Lambda expression for Callable vs Supplier

[Vicky Roy]

Hi,
Another doubt from OCP book (Page Number 343) regarding the below snippet:

Here under main method, 1st statement is compiled and 2nd/3rd can't be compiled. For 3rd statement reason is "The use() method is overloaded to take both Callable and Supplier parameters. The compiler does not take into account the fact that the body of the lambda expression happens to throw an exception; therefore, it does not know how to tell them apart." means compiler not able to understand that this lambda expression is throwing checked exception so it is not able to decide which method to be mapped. Now for 2nd statement the reason is "does not compile, as Supplier does not support checked exceptions.".

Isn't 2nd statement's justification contrary to the justification for line 3rd. 3rd statement is not able to compile because compiler is not able to understand that lambda expression is throwing exception but for 2nd statement, compiler is able to understand that lambda expression is throwing checked exception. how?

public class AmbiguousLambdaSample {
	public static void useCallable(Callable<Integer> expression) {}

	public static void useSupplier(Supplier<Integer> expression) {}

	public static void use(Supplier<Integer> expression) {}

	public static void use(Callable<Integer> expression) {}

	public static void main(String[] args) {
		useCallable(() -> {
			throw new IOException();
		}); // COMPILES
		useSupplier(() -> {
			throw new IOException();
		}); // DOES NOT COMPILE
		use(() -> {
			throw new IOException();
		}); // DOES NOT COMPILE
	}
}

Thanks,
Vicky

[praveen kumaar]

Vicky Roy wrote:Here under main method, 1st statement is compiled and 2nd/3rd can't be compiled. For 3rd statement reason is "The use() method is overloaded to take both Callable and Supplier parameters. The compiler does not take into account the fact that the body of the lambda expression happens to throw an exception; therefore, it does not know how to tell them apart." means compiler not able to understand that this lambda expression is throwing checked exception so it is not able to decide which method to be mapped. Now for 2nd statement the reason is "does not compile, as Supplier does not support checked exceptions.".  
Isn't 2nd statement's justification contrary to the justification for line 3rd. 3rd statement is not able to compile because compiler is not able to understand that lambda expression is throwing exception but for 2nd statement, compiler is able to understand that lambda expression is throwing checked exception. how?

the question,lambda expression(inside it's body) can throw checked exception or not,it solely depends on the implementation policy of lambda expression i.e.how really are you using or implementing lambda in code,in your case you have used the lambda expression as a method arguments,now see

useCallable(()->throw new IOException;)

here lambda is a Callable,this part will compile because call method of Callable is allowed to throw Exception,if needed,mentioned well in Callable API.

useSupplier(()->throw new IOException;)

here the lambda is a Supplier,and it has "get" method where it is not allowed to throw any Exception,though you can handle them inside the lambda body by using try-catch block.mentioned well in Supplier API you can see inside API,in the signature of get method,it is not allowed to throw Exception.

use(()->throw new IOException;)

lambda is undefined here so the compiler will get confused to opt b/w the overload method "use",as compiler will fail during parsing the target type of lambda expression(whether it is Callable or Supplier type) used as a method argument.

so finally compiler can understand well that lambda is throwing exception but deny for it if lambda tries to break the policy(for,it is used as).
Hope this will help!

Kind Regards,
Praveen.

[Vicky Roy]

here the lambda is a Supplier,and it has "get" method where it is not allowed to throw any Exception,though you can handle them inside the lambda body by using try-catch block.mentioned well in Supplier API you can see inside API,in the signature of get method,it is not allowed to throw Exception.

use(()->throw new IOException;)

lambda is undefined here so the compiler will get confused to opt b/w the overload method "use",as compiler will fail during parsing the target type of lambda expression(whether it is Callable or Supplier type) used as a method argument.

so finally compiler can understand well that lambda is throwing exception but deny for it if lambda tries to break the policy(for,it is used as).
Hope this will help!

Kind Regards,
Praveen.

Here how you can say that lambda is Supplier in case of use() method? It can be Callable or Supplier as defined for 1st and 2nd statement. And it should be mapped with Callable statement once compiler sees that it is throwing exception!!! That's what my understanding is

[praveen kumaar]

vicky,please read the explanation accordingly with the code.i had written a code line first and then explained it,so please read it with this order.
the line lambda is a supplier is for 2nd code snippet i.e., useSupplier() method.

Kind Regards,
Praveen.

[Vicky Roy]

praveen kumaar wrote:vicky,please read the explanation accordingly with the code.i had written a code line first and then explained it,so please read it with this order.
the line lambda is a supplier is for 2nd code snippet i.e., useSupplier() method.

Kind Regards,
Praveen.

Sorry for misunderstanding. Here my question is rephrased. Why lambda is undefined here? Earlier compiler was easily to map it with Supplier/Callable but why not now?

use(()->throw new IOException;)

lambda is undefined here so the compiler will get confused to opt b/w the overload method "use",as compiler will fail during parsing the target type of lambda expression(whether it is Callable or Supplier type) used as a method argument.

[Dave Tolls]

The compiler uses the signature of the methods to decide on the method.

After it has found the method in question, it will then check the code is valid.

The use() lambda fails because it cannot determine which method you mean...the one in Callable or the one in Supplier, so it doesn't even get to checking the code.

[praveen kumaar]

Vicky Roy wrote:Sorry for misunderstanding. Here my question is rephrased. Why lambda is undefined here? Earlier compiler was easily to map it with Supplier/Callable but why not now?

Because the previous two methods are not overloaded and compiler will easily finds what is the type of lambda from the method signature where you declared them.
But in the last case the method "use" is overloaded with 2 types of argument(Callable,Supplier) and both of them returns a void.lambda cannot express its type on its own,compiler interprets its type from the term "target typing",and compiler deduct it from the context in which it is used.please read the item target-typing here in this Target Typing in lambda From Oracle..

Vicky Roy wrote:Sorry for misunderstanding.

No worries,it's ok.

hope this will help!

kind regards

[Vicky Roy]

Still I would argue. In case of Use() when compiler checks that it is showing exception, then it should map this call with the method expecting Callable since it only supports checked exceptions!!! That's what happened in case of 1st statement.

[Henry Wong]

Vicky Roy wrote:Still I would argue. In case of Use() when compiler checks that it is showing exception, then it should map this call with the method expecting Callable since it only supports checked exceptions!!! That's what happened in case of 1st statement.

The compiler doesn't check for exceptions as part of the signature. And you can't really argue with the compiler -- it will fail to compile every time...

As for the case of the first statement, there was only one option. The compiler did not have to disambiguate the method call.

Henry

[Vicky Roy]

Henry Wong wrote:

Vicky Roy wrote:Still I would argue. In case of Use() when compiler checks that it is showing exception, then it should map this call with the method expecting Callable since it only supports checked exceptions!!! That's what happened in case of 1st statement.

The compiler doesn't check for exceptions as part of the signature. And you can't really argue with the compiler -- it will fail to compile every time...

As for the case of the first statement, there was only one option. The compiler did not have to disambiguate the method call.

Henry

Fine. Then lets say I agree what you are saying that compiler doesn't understand the exception and it can't decide appropriate method. But then why useSupplier() is not compiling? Since compiler can't understand the exception, it should easily map and error may come at runtime!!!

[Henry Wong]

Vicky Roy wrote:
Fine. Then lets say I agree what you are saying that compiler doesn't understand the exception and it can't decide appropriate method. But then why useSupplier() is not compiling? Since compiler can't understand the exception, it should easily map and error may come at runtime!!!

The compiler does not use the checked exception to resolve overloaded methods. However, once a method is resolved, then it makes sure that checked exceptions are either caught or declared as throws.

Henry

[Vicky Roy]

Henry Wong wrote:

Vicky Roy wrote:
Fine. Then lets say I agree what you are saying that compiler doesn't understand the exception and it can't decide appropriate method. But then why useSupplier() is not compiling? Since compiler can't understand the exception, it should easily map and error may come at runtime!!!

The compiler does not use the checked exception to resolve overloaded methods. However, once a method is resolved, then it makes sure that checked exceptions are either caught or declared as throws.

Henry

ok Thanks. Now I think I can co-relate this statement with the output.

[Stephan van Hulst]

The method signature determines what the return type of the lambda expression should be, and not the other way around. With useSupplier(), the compiler knows that the lambda expression should return a Supplier<Integer>. After it's done that, it checks that the lambda expression indeed returns such a type. It does not, because Supplier<Integer> is not allowed to throw an exception.

The compiler can only use the left hand side of the lambda expression (the parameter list) to determine which overloaded version of the method to call, but it can only do that if you explicitly state the type of the parameters:

  public static void use(Function<String, Boolean> stringPredicate) {}

  public static void use(Predicate<Integer> intPredicate) {}

  public static void main(String[] args) {
    use((String  a) -> a.equals(a)); // uses the Function<String,Boolean> version
    use((Integer a) -> a.equals(a)); // uses the Predicate<Integer> version

    use(a -> a.equals(a)); // compiler error, ambiguous
  }