Java: compile-time resolution and “most specific method” as it applies to variable arity

Question

Could someone help me understand section 15.12.2.5 of the JLS re: most specific method?

(bludgeoned cut&paste from JLS follows)

In addition, one variable arity member method named m is more specific than another variable arity member method of the same name if either:

• One member method has n parameters and the other has k parameters, where n >= k. The types of the parameters of the first member method are T1, . . . , Tn-1 , Tn[], the types of the parameters of the other method are U1, . . . , Uk-1, Uk[]. If the second method is generic then let R1 ... Rp p1, be its formal type parameters, let Bl be the declared bound of Rl, 1lp, let A1 ... Ap be the actual type arguments inferred (§15.12.2.7) for this invocation under the initial constraints Ti << Ui,1ik-1, Ti << Uk, kin and let Si = Ui[R1 = A1, ..., Rp = Ap] 1ik; otherwise let Si = Ui, 1ik. Then: for all j from 1 to k-1, Tj <: Sj, and, for all j from k to n, Tj <: Sk, and, If the second method is a generic method as described above then Al <: Bl[R1 = A1, ..., Rp = Ap], 1lp.
• One member method has k parameters and the other has n parameters, where n >= k. The types of the parameters of the first method are U1, . . . , Uk-1, Uk[], the types of the parameters of the other method are T1, . . ., Tn-1, Tn[]. If the second method is generic then let R1 ... Rp p1, be its formal type parameters, let Bl be the declared bound of Rl, 1lp, let A1 ... Ap be the actual type arguments inferred (§15.12.2.7) for this invocation under the initial constraints Ui << Ti, 1ik-1, Uk << Ti, kin and let Si = Ti[R1 = A1, ..., Rp = Ap] 1in; otherwise let Si = Ti, 1in. Then: for all j from 1 to k-1 , Uj <: Sj, and, for all j from k to n , Uk <: Sj, and, If the second method is a generic method as described above then Al <: Bl[R1 = A1, ..., Rp = Ap], 1lp.

Ignoring the issue generics, does this mean varargs is more important than subtyping, or subtyping is more important than varargs, when deciding whether one method is more specific than another? I can't figure it out.

Concrete example: Which of the following compute() methods is "more specific" according to the JLS?

package com.example.test.reflect;

class JLS15Test
{
    int compute(Object o1, Object o2, Object... others) { return 1; }
    int compute(String s1, Object... others)            { return 2; }

    public static void main(String[] args) 
    {
        JLS15Test y = new JLS15Test();
        System.out.println(y.compute(y,y,y));
        System.out.println(y.compute("hi",y,y));
    }
}

I can't figure out which is "more specific"; the output prints

1
2

I'm confused how to interpret the results. When the first argument was a String, the compiler picked the method with the more specific subtype. When the first argument was an Object, the compiler picked the method with the fewer number of optional varargs.

---

NOTE: If you are not reading this section of the JLS, and you are giving an answer that depends on the types of the arguments, you are not helping me. If you carefully read the JLS, other than the parts relating to generics, the definition of "more specific" depends on the declared arguments, not on the actual arguments -- this comes into play in other parts of the JLS (can't find it at the moment).

e.g. for fixed arity methods, compute(String s) would be more specific than compute(Object o). But I'm trying to understand the relevant section of the JLS re: variable arity methods.

Answer 1

1. int compute(String s1, Object... others) is more specific when you call compute("hi",y,y), since String is a subclass of Object.

2. int compute(Object o1, Object o2, Object... others) is the only match for compute(y,y,y) because the second method receives String as first param, and JLS15Test is not a subclass of String

EDIT

My answer resides on the basics of specific methods, but your code only compiles because of the ability of the compiler to distinguish between the methods in the way described above.

The following examples will not even compile because of its ambiguity:

case 1:

int compute(Object o1, Object o2, Object... others) { return 1; }
int compute(Object s1, Object... others)            { return 2; }

public static void main(String[] args) 
{
    JLS15Test y = new JLS15Test();
    System.out.println(y.compute(y,y,y));
    System.out.println(y.compute("hi",y,y));
}

case 2:

int compute(String o1, Object o2, Object... others) { return 1; }
int compute(Object s1, String... others)            { return 2; }

public static void main(String[] args) 
{
    JLS15Test y = new JLS15Test();
    System.out.println(y.compute("hi","hi","hi"));
}

More Edit

I didn't get your question well the first two times (and I hope I do this time :) ).

The actual case you are talking about will look like that:

public class Test {
    public static void main(String[] args)
    {
        Test t = new Test();
        int a = t.compute("t", new Test());
        System.out.println(a);
    }

    int compute(String s, Object... others) { return 1; }
    int compute(Object s1, Object others)   { return 2; }
}

In this case, compute(Object s1, Object others) is indeed more specific then compute(String s, Object... others) (has less parameters) so the output will be 2 indeed.

Answer 2

After reading the JLS multiple times, I finally think I understand this section.

What they are saying is that if there are two variable-arity methods, for the purposes of deciding which is "more specific", you can consider the one with the shorter argument list to be extended so that is of equal length to the longer one. e.g.

int compute(Object o1, Object o2, Object... others)
int compute(String s1, Object... others)

can be considered (only for the purposes of "more specific") to be equivalent to

int compute(Object o1, Object o2, Object... others)
int compute(String s1, Object,    Object... others)

and then the argument types are compared, one by one, with the latter method being more specific.

(more rigorously, the first one has n = 3, k = 2, n >= k, with String <: Object [String is a subtype of Object] and the JLS dictates comparing the types directly of each parameter for j between 1 and k-1 [one less than the shorter length], comparing the vararg type of the shorter method signature with the remaining parameters of the longer method.)

In the following case:

int compute(Object o1, Object o2, String... strings)
int compute(Object o1, String... strings)

these would be equivalent (only for the purposes of "more specific") to

int compute(Object o1, Object o2, String... strings)
int compute(Object o1, String,    String... strings)

and the latter more specific.

So variable-arity never trumps subtyping for the purposes of comparing "more specific" methods which are both of variable arity.

However, fixed-arity methods are always considered first (JLS 15.12.2.2 and 15.12.2.3) before variable-arity methods.

Answer 3

The second compute call prints 2 because the literal "hi" is known to be a String at compile time, so the compiler choses the second method signature because String is more specific than Object.