DEV Community: Yuriy F

Same named methods in Java. Part 2: When Generics Warp Overload Resolution

Yuriy F — Mon, 06 Oct 2025 19:54:31 +0000

As we learned in Part 1 of this series, Don’t Underestimate Overloading, overloading is about guessing. The compiler is trying to guess which method to execute, based on the types of parameters you pass. Generics add another layer of guessing called type inference. That’s the compiler trying to guess the parameter types from the context before deciding which overload to pick. For this part, again, we’ll leave compilation errors aside — those are safe because the compiler and IDEs do a good job pointing them out right away. t is more dangerous when code compiles but a different method is called than expected. Or when a “harmless” signature change causes a different overload to be picked. We are also not going to touch inheritance - we will dive into it in future parts.

Let’s check this example we’ll review later:

import java.io.Serializable;

public class Teaser<T> {
        <T extends Serializable> void m(T a) { System.out.println("m(T)"); }
                                 void m(T a) { System.out.println("m(instance T)");}

        public static void main(String[] args) {
            new Teaser<Long>().m(1);
            new Teaser<Integer>().m(1);
        }
}

Output:

m(T)
m(instance T)

We can see two calls that look nearly identical end up taking different paths, all because of how generics, inference, and overloading interact.

Before we dive into inference and overload resolution, let us take a quick step back. Generics in Java are a way to parameterize types. Instead of writing the same code for String, Integer, List, etc., we use a type parameter, like T, and then the compiler substitutes it in.

Generics can be declared at two different levels:

Type level — the type parameter is attached to the whole type:

class Box<T> { 
  T value; 
  void set(T v) { value = v; } 
}

Method level — the type parameter exists only for that method:

class Utils { 
   static <T> T identity(T t) { return t; } 
}

To simplify, we’ll start with method-level generics only, since that is where inference and overload resolution play together most directly. Once we’ve covered how the compiler “guesses” method-level types, we’ll bring class-level generics back in and see how they make things even more complicated.

With generics involved, the compiler has to juggle two separate decisions at once:

Which type variable substitutions make the call type-correct.
Which overload is the most specific match once those substitutions are made.

Sometimes these guesses reinforce each other, and everything looks obvious. Other times, they clash, and you get outcomes that seem counter-intuitive. That is why two almost identical calls may resolve to different methods, or why a method that looks like a perfect candidate isn’t even considered applicable.

Generics in Java are tied to two separate compile-time processes. Both happen before your code ever reaches the JVM, but they serve very different purposes:

Type inference is how the compiler figures out which types to plug in when choosing a method. This guides overload resolution and ensures type safety without requiring you to spell out every <T> explicitly.
Type erasure is what the compiler does after that choice, to generate valid bytecode for the JVM.

Let’s look at this example:

static <T> T pick(T a, T b) { return a; }

public static void main(String[] args) { 
        // infers T = Integer
        var a = pick(1, 2); 

        // infers T = Comparable<? extends Object>
        var b = pick(1, (Comparable<?>)2); 

        // infers T = Number & Constable & ConstantDesc & Comparable<? extends Number & Comparable<?> & Constable & ConstantDesc>
        var c = pick(1, 2L); 
}

The compiler guesses T differently depending on context — that’s type inference. The method declaration, after compilation, is erased to:

pick(Object, Object)

Bounded generics add constraints to a type variable: T must be a subtype (or an implementation) of some bound. The common form is an upper bound with extends, e.g. <T extends Number>, and you can have intersection bounds like <T extends Number & Comparable<T>>. Bounds affect applicability (an overload with <T extends CharSequence> can’t accept Object) and often affect specificity (a bounded parameter is considered “tighter” than an unbounded <T> when both are applicable). That’s why introducing or tightening a bound can silently change which overload the compiler picks, while everything still compiles.

In the example below:

static <T extends Number> void pick(T a, T b)

will be erased to:

void pick(Number, Number)

public class Example {
    static <T>                void pick(T a, T b) { System.out.println("Unbounded"); }
    static <T extends Number> void pick(T a, T b) { System.out.println("Bounded"); }

    public static void main(String[] args) {

        // infers T = Serializable & Comparable<? extends Serializable & Comparable<?> & Constable & ConstantDesc> & Constable & ConstantDesc
        pick(1, "a"); //Prints Unbounded

        // infers T = Integer
        pick(1, 2); //Prints Bounded

        Object n = 2;
        // infers T = Object
        pick(1, n);  //Prints Unbounded
    }
}

In all three calls, inference first tries to find a single T that fits both arguments; then overload resolution picks the most specific applicable method:

For pick(1, "a"), the bounded overload <T extends Number> is not applicable ( "a" isn’t a Number ), so the unbounded version wins; the compiler chooses an intersection type that both Integer and String satisfy (e.g., Serializable & Comparable<?> & Constable & ConstantDesc).
For pick(1, 2), both overloads are applicable with T = Integer, and the bounded one is more specific, so it prints Bounded.
For Object n = 2; pick(1, n), the static types are Integer and Object; the bounded overload can’t accept Object (not a Number), but the unbounded one can infer T = Object, so it prints Unbounded.

But what if argument types are not available? Let’s look at another example:

public class NullPick {
    static <U>                U m(U u) { System.out.println("m(U)"); return u;}
    static <U extends Number> U m(U u) { System.out.println("m(U extends Number)"); return u;}

    public static void main(String[] args) {
        //infers U = Integer
        Integer s = m(null); //Prints m(U extends Number)

        //infers U = Number
        Object o = m(null);  //Prints m(U extends Number)
    }
}

For both calls, null fits any reference type and is no help for the type inference. Both declared methods are applicable for both calls, i.e. can handle null. And m( U extends Number)wins in both cases as a more specific method for the arguments.

But what if I add another call:

String s = m(null);

It causes a compilation error instead of a seemingly logical choice - the first method declared, “<U> U m(U u)”. The reason is that m(U extends Number) is still most specific, and cannot return String. And if I want this call to compile, I need to give an additional hint:

String t = NullPick.<String>m(null);

String t = m((String)null);

Note that while the return type is inferred, it does not participate in overload resolution.

The type could be bound to at most one class and to multiple interfaces. If there is a class, it must appear first (leftmost). The erasure will use the leftmost type.

For example methods defined here:

public class Example {
    static <T extends Number & Comparable<T> >      T m(T a) { return a;}
    static <T extends Serializable & Comparable<T>> T m(T a) { return a;}
    static <T extends Comparable<T> & Serializable> T m(T a) { return a;}
}

Are erased to :

static Number m(Number)
static Serializable m(Serializable)
static Comparable m(Comparable)

But in this case, even though erasures are different, the compiler will not be able to pick between the last two methods, so both are unusable in practice.

Now let’s look at the example (we remove one of the ambiguous methods ):

public class Example {
    static <T extends Number & Comparable<T>>       void m(T a) { System.out.println("Number");}
    static <T extends Comparable<T> & Serializable> void m(T a) { System.out.println("Serializable");}

    public static void main(String[] args) {
        m(1); //Prints Number
        m(null); //Prints Number
        m(""); //Prints Serializable
    }
}

First two calls print Number. The reason is Number actually implements Serializable, so it is the more specific candidate. The last call does not extend Number, but it does implement Comparable and Serializable, which provides enough argument type information for the compiler to pick a method.

Now let’s see how adding Type level generics definitions affect the overload resolution. Check out the code below and compare it to NullPick example:

class X<T>{
    <U  extends Number> U m(U u){System.out.println("m(U extends Number)");return u;}
                        T m(T t){System.out.println("m(T)");return t;}
}

public class ClassLevelGeneric<T> {
    public static void main(String[] args) {
        X<Long> i = new X<>();
        var a = i.m(1);    //Prints m(U extends Number)
        var b = i.m(null); //Prints m(T)
        var c = i.m(1L);   //Prints m(T)
        double x = 'a';
        var d = i.m(x);    //Prints m(U extends Number)
    }
}

Even though by erasure, <U extends Number> U m(U u) is more specific than T m(T t) we see that m(null) and m(1L) resolve to the T m(T t) method.

With all that in mind, let’s take another look into the teaser from the beginning of the article:

import java.io.Serializable;

public class Teaser<T> {
        <T extends Serializable> void m(T a) { System.out.println("m(T)"); }
                                 void m(T a) { System.out.println("m(instance T)");}

        public static void main(String[] args) {
            new Teaser<Long>().m(1);
            new Teaser<Integer>().m(1);
        }
}

The first call passes an Integer, and out of two methods, one taking Long and one taking something that extends Serializable, only the Serializable one is eligible.

The second call also passes an Integer. But now we have both methods eligible: one taking an Integer and one taking a Serializable. The Integer one is more specific and wins.

One thing to keep an eye on — the T in <T extends Serializable> void m(T a) and the T in Teaser<T> are two different, absolutely unrelated type variables.

But what if we just do new Teaser().m(null) ? This way we have two methods, one expecting something that extends Serializable, and one that takes Object. Serializable one is more specific and wins, printing m(T).

Now, let’s look at wildcards. A wildcard means “some unknown type” and depicted with “?”. You mostly see it as ? extends T (a producer you read from) and ? super T (a consumer you write to). They exist because generics are invariant: List<Integer> is not a List<Number>. Wildcards let you accept families of types safely. In Java, you most often see it all over the Collections API.

Example:

import java.io.Serializable;

class Repo<T>{ }

public class Demo{
    static Repo<? super Number> m(Repo<? super Number> r, Integer a)
    { System.out.println("Wildcard");return r;}
    static Repo<? extends Comparable<?>> m(Repo<? extends Comparable<?>> r, String a)
    { System.out.println("Extends");return r;}

    public static void main(String[] args) {
        Repo<Number> number = new Repo<>();
        Repo<Serializable> serializable = new Repo<>();
        Repo<Integer> integer = new Repo<>();
        Repo<Double> dbl = new Repo<>();

        var ir = m(number, null); //Prints Wildcard
        var ic = m(serializable, null); //Prints Wildcard
        var di = m(integer, null); //Prints Extends
        var dr = m(dbl, null); //Prints Extends
    }
}

Since Repo<? super Number> and Repo<? extends Comparable<?>> both erased to Repo, we can have same-named methods handling each. So we did a little trick: we add a second argument and set it to null explicitly in the method calls, so no type information could be inferred from it by the compiler. For this to work there should also be no relation between those arguments type, so neither is more specific for the null constant.

What’s going on:

m(Repo<? super Number>, Integer) (“Wildcard”)

Works for Repo<Number> and also Repo<Serializable>: ? super Number means “Number or any supertype of Number,” and yes, interfaces count—Number implements Serializable, so Serializable qualifies.
<T extends Comparable<T>> m(Repo<T>, String) (“Extends”)

Grabs Repo instances whose element type is self-comparable: Integer, Double, etc. Number and Serializable don’t meet that bound, so they fall back to the “Wildcard” method. Here you handle the precise element type (Repo<Integer>, Repo<Double>).

Here is a simple example of using wildcards with collections:

import java.util.ArrayList;
import java.util.Collection;
import java.util.List;

public class ExampleCollections {
    void m(Collection<?> c)                 { System.out.println("Collection<?>"); }
    void m(List<? extends Number> numbers)  { System.out.println("List<? extends Number>"); }

    public static void main(String[] args) {
        List<String> a = new ArrayList<>();
        List<Integer> b = new ArrayList<>();

        new ExampleCollections().m(a); // Prints Collection<?> 
        new ExampleCollections().m(b); // Prints List<? extends Number>
    }
}

And finally let’s take a look at another code snippet:

import java.util.ArrayList;
import java.util.List;


public class MultiType{
    static <T extends Comparable<T>> void m(T t, T u)
    { System.out.println("Same type, extends Comparable");}

    static <T, U> void m(T a, U b){System.out.println("Unbound types");}

    static <T> void m(List<T> t, List<T> u){ System.out.println("Same lists");}

    public static void main(String[] args) {
        m(1.0, 1); //Prints Unbound types

        m(1, 1); //Prints Same type, extends Comparable

        List<Integer> a = new ArrayList<>();
        List<String> b = new ArrayList<>();
        m(a, b); //Prints Unbound types

        List c = a;
        List d = b;
        m(c, d); //Prints Same lists
    }
}

m(1.0, 1)

The “same-type” overload needs a single T that works for both arguments and that T must implement Comparable<T>. Double and Integer don’t share that one T, so the catch-all <T,U> takes the call.
m(1, 1)

Both args are Integer, and Integer implements Comparable<Integer>. The same-type overload fits and is more specific than <T,U>.
m(a, b)

Generics are invariant: List<Integer> and List<String> can’t both be List<T> with the same T. The same-lists overload is out; <T,U> wins.
m(c, d) where c and d are raw List

Erasing element types makes both parameters look like plain List. That makes m(List<T>, List<T>) applicable (you’ll get an unchecked warning), and it beats the <T,U> version here.

Generic method overloading in Java boils down to a two-step guessing game: infer the types, then pick the most specific method. The tricky part is that inference, bounds, and specificity all influence each other, so tiny changes—swapping an argument type, tightening a bound, or just passing null—can completely flip which method gets called. While writing this article, I tested both Claude and GPT on picking the right method; they got roughly a third of the cases wrong, with total confidence. If AI struggles with this, you're in good company when it confuses you too.

Same named methods in Java. Part 1: Don’t Underestimate Overloading

Yuriy F — Thu, 18 Sep 2025 15:24:14 +0000

Recently I posted a poll on LinkedIn about method selection in overloaded method calls and was rather surprised that only 20% of the answers were correct. That gave me a push to do this write-up, as I feel that same-named methods do not get the credit they deserve for the mess they can cause.

I plan to continue this as a series. We’ll look at overloading with generics, the role of functional interfaces and lambdas, what happens with inheritance and overriding, and cases involving static imports and visibility across types. This part will look at method overloading within a single type definition (class, interface, or enum). Basically, we’re going to examine how the most specific method is selected by only looking at method arguments.

Throughout this article, I am not going to get into the different cases of compilation errors, as build process and IDEs are taking a good care of those.

To start the confusion, let’s look at a short example of two classes (all overloads are defined in one class, just as we talked):

public class Example1 {
    public static class Helper {
        private void m(double num)      { System.out.println("m(double)"); }
        public  void m(char... chars)   { System.out.println("m(char...)"); }
        public  void m(Comparable c) { System.out.println("m(Comparable)"); }
        public  void m(Object obj)      { System.out.println("m(Object)"); }
    }

    public static void main(String... args) {
        Helper h = new Helper();
        h.m('a');
    }
}

import Example1.Helper;

public class Example2 {
    public static void main(String... args) {
        Helper h = new Helper();
        h.m('a');
    }
}

Execution of Example1 prints:
m(double)

Execution of Example2 prints:
m(Comparable)

Why does this happen? We’ll come back to this puzzle after covering some ground.

The biggest danger with overloading, is that a change to a method signature or addition of a new method may change which method is getting executed by an unsuspecting caller, as it may not give you any error or even a warning. For the scope of this article it is somewhat simple, though not always obvious. But once we get to the next parts it will be progressively harder to spot.

When two methods share the same name in Java, they may participate in overloading, overriding, or hiding, depending on their signatures, modifiers, and inheritance hierarchy. I will try to keep my examples short, but I have to say, the mess you can create by combining all three is incredible.

The idea of overloading is actually older than OOP itself—FORTRAN already let you write ABS for integers or floating-point numbers in the 1950s. C++ in the 1980s then brought user-defined function overloading into mainstream OOP, and Java inherited it from day one. The idea behind it is to improve readability and API consistency by using the same logical name for conceptually similar operations and to allow API growth by adding new overloads without breaking code.

So, what is overloading about?

First the formal JLS definition (JLS 8.4.9 https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.9):

if two methods of a class (whether both declared in the same class, or both inherited by a class, or one declared and one inherited) have the same name but signatures that are not override-equivalent, then the method name is said to be overloaded. This fact causes no difficulty and never by itself results in a compile-time error. There is no required relationship between the return types or between the throws clauses of two methods with the same name, unless their signatures are override-equivalent.

Since in this part we only going to look at methods defined within a single type, we are going to ignore “override-equivalent”, "inherited" or even not mentioned imported static functions (we will go overall of it in details in Part three) and just say:
if a type declaration contains methods with the same name those methods are overloaded.
This applies regardless of differences in return type, number of parameters, whether the methods are static or instance methods, or their access level. This also assumes there is no compile time error.

Note: if your class defines more than one constructor, they are considered overloaded just like methods. All of the overload resolution rules we discuss here apply to constructors as well.

Example:

static void m(int x) {}
private int m() { return 0; }
public String m(int x, long y) { return ""; }

Overloading is all about the compiler choosing a method to execute for you. Since it is in the compiler’s realm, this decision is made by the time the compiler has done its job, and it may or may not match your intent. It is not going to be changed at runtime, and if something changes you have to recompile. Let me show what I mean.

Example:

We have two classes, Main and Helper:

package team1;
public class Helper {
    public void m(Object o) {
        System.out.println("m(Object)");
    }
}

import team1.Helper;
public class Main {
    public static void main(String... args) {
       new Helper().m("test");
    }
}

Let’s assume that the team that wrote class Main doesn’t have any control over the class Helper, and it is provided by another team in the form of a JAR file.

When you build and execute main, it produces the following output:
m(Object)

Now let’s prove that if we change method m in the Helper class, the JVM will pick up the change without recompiling Main. This should work just fine as per the JLS 13.4.22: “Changes to the body of a method or constructor do not break compatibility with pre-existing binaries.”

Lets edit the Helper class and rebuild the jar:

package team1;
public class Helper {
    public void m(Object o) {
        System.out.println("V2 m(Object)");
    }
}

Now we rerun Main, and see the new output:
V2 m(Object)

Okay, it’s obviously picked up. Now it’s time to change Helper again and repeat the process. We are going to add a new method to it, which is again fine per the JLS 13.4.12: “Adding a method to a class does not break compatibility with pre-existing binaries.”

package team1;
public class Helper {
    public void m(String o) {
        System.out.println("m(String)");
    }

    public void m(Object o) {
        System.out.println("V2 m(Object)");
    }
}

Just looking at the code, in theory, the call to new Helper().m("test") should print:
m(String)

But since Main is not recompiled, we will still get:
V2 m(Object)

And only after we recompiled Main with the new JAR and run it, we will get:
m(String)

This clearly shows that overload resolution happens at compile time: without recompiling Main, the JVM cannot pick the newly added m(String) overload. Note, no changes to the class Main were done. No methods were modified. A new method was added and the compiler decided it is a better fit for the name and parameters you provided.

This is what happens when compiler is picking a method for you. It is described in JLS 5 ( https://docs.oracle.com/javase/specs/jls/se24/html/jls-5.html ): Conversions and Contexts and §15.12 ( https://docs.oracle.com/javase/specs/jls/se24/html/jls-15.html#jls-15.12 ): Method Invocation Expressions. But here is the simplified set of rules, if we take inheritance and generics out.

Determine Type to Search. Figure out the name of the method to be invoked and which type to search for definitions of methods of that name.

Determine Method Signature. Using the name of the method and the argument expressions, locate methods that are both accessible and applicable, that is, declarations that can be correctly invoked on the given arguments.

Identify Potentially Applicable Methods. Keep only methods whose parameter lists could match the arguments, excluding obviously impossible.

Identify Matching Arity Methods Applicable by Loose Invocation. Try to match without using varargs. For each candidate, check if every argument can be converted to the corresponding parameter using method-invocation conversions.

Identify Methods Applicable by Variable Arity Invocation. If no fixed-arity method worked, try varargs.

Choosing the Most Specific Method. If multiple applicable overloads remain, pick the most specific:

Exact match > widening primitive > boxing/unboxing > reference upcast > varargs. Let’s have a small recap there:
1. Widening primitive - implicit conversion of primitive types, for example int to long, or char to double. ( https://docs.oracle.com/javase/specs/jls/se24/html/jls-5.html#jls-5.1.2 )
2. Boxing/Unboxing - conversions of primitive types to a corresponding reference type, for example from int to Integer or char to Character. ( https://docs.oracle.com/javase/specs/jls/se24/html/jls-5.html#jls-5.1.7 )
3. Reference upcast - conversion of a Child type to the Parent type. Integer to Number or Integer to Object. ( https://docs.oracle.com/javase/specs/jls/se24/html/jls-5.html#jls-5.1.5 )
4. Varargs - (variable arity parameters) let a method accept zero or more arguments of the same type. At compile time, the arguments are packaged into an array and passed to the method. ( https://docs.oracle.com/javase/specs/jls/se24/html/jls-8.html#jls-8.4.1 )
Among reference types, the subtype parameter wins (e.g., anything > Object, Integer > Number, etc.)
For competing varargs, compare their element types with the same priorities
If no single winner exists → ambiguous method call error.

Is the Chosen Method Appropriate? Correct receiver kind (static vs instance), still accessible, and any required unchecked conversions/generic warnings are accounted for. If this fails, it’s a compile-time error.

Lets look at some examples:

Example 1. At this point let’s look at the puzzle from the beginning of this article.

public class Example1 {
    public static class Helper {
        private void m(double num)      { System.out.println("m(double)"); }
        public  void m(char... chars)   { System.out.println("m(char...)"); }
        public  void m(Comparable c) { System.out.println("m(Comparable)"); }
        public  void m(Object obj)      { System.out.println("m(Object)"); }
    }

    public static void main(String... args) {
        Helper h = new Helper();
        h.m('a');
    }
}

import Example.Helper;
public class Example2 {
    public static void main(String... args) {
        Helper h = new Helper();
        h.m('a');
    }
}

In the main method of Example1:

Private methods of inner class are accessible in the outer class, so all 4 methods could be applied

'a' could be converted to double through primitive widening and to Character through boxing. But primitive widening beats boxing.

Since there is fixed arity method available varargs are not looked into. Therefore m(double) is called

In the main method of Example2:

Private method is not accessible, so it is not one of the candidates

'a' could be converted to Character. Character reference could be upcasted to Comparable or to Object. Comparable is more specific

Varargs are not looked into. Therefore m(Comparable) is called.

Example 2. Let’s look into another case:

public class Example2 {
    static void m(Double a) { }
    static  void m(int...a) {}

    public static void main(String... arg) {
        m(Integer.valueOf(1));
    }
}

Integer.valueOf(1) is an Integer, so it cannot be converted to Double. Therefore m(int...) is the only one method available.

public class Example2 {
    static void m(double a) { }
    static  void m(int...a) {}

    public static void main(String... arg) {
        m(Integer.valueOf(1));
    }
}

However, Integer is unboxed to int primitive, that widens to double, so m(double) is picked int this example. A fun note, in this example I could have replaced m(Integer.valueOf(1)) with m(Character.valueOf('a')) and get the same result in both cases. Note how the second class went to Unboxing and then to widening ( Integer - > int -> double ), but Unboxing -> widening -> Boxing is not happening.

Example 3. Lets move to multiple arguments:

public class Example3 {
    static void m(Object a, Object b) { }
    static  void m(int...a) {}

    public static void main(String... arg) {
        m(1,1);
    }
}

m(1,1) in this case going to execute m(Object, Object). Note that m(), m(1), m(1,1,1), though, will all call m(int...)

Example 4.

public class Example4 {
    static void m(float a, long b) { }
    static  void m(int a, Character b) {}

    public static void main(String... arg) {
        m(1,'a');
    }
}

Obviously, m(float, long) is going to be executed here. (widening beats Boxing)

Example 5.

public class Example5 {
    static void m(Serializable a, String...c) { }
    static  void m(String...c) { }

    public static void main(String... arg) {
        m();
        m("a");
        m("a","b");
        m("a","b", "c");
        m('a');
    }
}

All calls except the last one are going to m(String...). Both methods declared go into a varargs category, and m(String...) is a more specific on the first 4 calls.

Example 6.

public class Example6 {
static void m(int a, float b, double c) { }
static void m(int a, float b, Integer c) { }

public static void main(String... arg) {
    m(1,2,3);
}

}

m(int, float, double). In this example the method with 3 primitives wins (widening vs Boxing). But if I change the last argument to be a vararg - not anymore.

public class Example6 {
    static void m(int a, float b, double... c) { }
    static void m(int a, float b, Integer c) { }

    public static void main(String... arg) {
        m(1,2,3);
    }
}

As we saw, overloading is resolved strictly at compile time. The compiler goes through the available methods, applies conversions if needed, and picks the most specific one it can find. Once the decision is made, it does not change at runtime. This explains why adding a new overload or slightly changing a signature may change which method is called without producing any errors or warnings.

Even in the simple case of a single type, the rules can lead to non-obvious results. Private visibility, static versus instance methods, varargs, boxing and unboxing, widening, and reference conversions all play a role in which overload is chosen.

This part only looked at concrete types in a single class, interface, or enum. In the next part we will move on to generics, where type inference, erasure, and unchecked conversions make the resolution rules even more subtle and much harder to predict.