Overload resolution regression

Zhong Yu zhong.j.yu at gmail.com
Tue Nov 19 09:19:50 PST 2013


Previously, the type of an argument is independent of the choice of
method. That justifies the "most specific method" mechanism - we have
this fixed argument that can be fed to two methods, and we choose the
method with a narrower signature for *that argument*.

In Java 8 that's no longer true. The argument can be a "poly
expression", the meaning of which depends on the choice of method. So
we are talking about different methods *and* different arguments.
There is no apparent justification why method signature alone is *the*
criteria for choosing among several possible *invocations*.

Zhong Yu


On Mon, Nov 18, 2013 at 6:43 PM, Jonathan Ross
<jonathan.ross at imc-chicago.com> wrote:
> Hi,
>
> I recently started porting a 150k-line project to jdk 8 to try my hand at
> the recent changes in the collection libraries. (Hadn't done this since
> last year, my apologies!)
>
> I have run in to a large number of compilation errors: regressions in type
> inference and overload resolution. A lot of these are in unit tests using
> mockito and fest and other similar monadic apis that rely heavily on
> overload resolution.
>
> The code snippet below is a distilled version of my typical compilation
> error: our test code relying on the compiler choosing the Object overload
> by default.
>
>
> import java.math.BigInteger;
>
> public class OverloadingRegression {
>
>     static <T> T unsafeCast(Object anObject) {
>         return (T) anObject;
>     }
>
>     public void showOverloadResolutionIssue() {
>         pickMe(unsafeCast(new String()));
>     }
>
>     private void pickMe(BigInteger o) { /* ClassCastException in
> 1.8.0-ea-b115 */ }
>
>     private void pickMe(Object o) { /* fine, picked in 1.6 & 1.7 */ }
> }
>
>
> Obviously the unsafeCast is not going to win any beauty prizes, but
> sometimes you just have to do this sort of thing.  My main point is: it
> used to work in java 7, it doesn't any more.
>
> Is this a known issue (or is it even expected behaviour)?
>
> I'm using 1.8.0-ea-b115, but I verified that it fails with all 1.8 jdks I
> have my box.  When I pass in -source 1.7 it does work. And when I do an
> explicit cast to Object (of course).
>
> -- Jonathan Ross
>


More information about the lambda-dev mailing list